Fixed dialog sizes
-
@pbean said:
That's another thing that I hope to see on Windows one day. Simply moving windows with a keypress (like the Windows button?), rather than being limited to the title bar. If a similar situation would arise on Windows, you would just be out of luck, since you can't drag windows past the top border of the screen.
1. Alt+Spacebar, M
2. Move with arrow keys
3. Press Enter
-
@BC_Programmer said:
@pbean said:
Doesn't Windows attach the title bar to the top of the screen if you try to move it off the screen using that method?[...]since
you can't drag windows past the top border of the screen.1. Alt+Spacebar, M
2. Move with arrow keys
3. Press Enter
-
@PJH said:
Doesn't Windows attach the title bar to the top of the screen if you try to move it off the screen using that method?
Nope.
You can take it anywhere.
-
@dhromed said:
<shrug> must be just XP it happens in then.@PJH said:
Doesn't Windows attach the title bar to the top of the screen if you try to move it off the screen using that method?
Nope.
You can take it anywhere.
-
@blakeyrat said:
@kilroo said:
[pedantic dickweed]You seem to have imagined one quite easily.[/pedantic dickweed]
... nope, sorry. I still think "8 MB to support all hardware" is more ludicrous.
... Ah. I didn't realize you hadn't made up your mind yet when you posted it. Or if you had, you neglected to say "No, not even that."
I'm almost inclined to give the edge to your suggestion, but only because of semantic dickweedery involving the distinction between the core kernel and loadable kernel modules...but if modules on Linux don't count toward the size of the kernel, they probably shouldn't count as not needing to download drivers separately, either.
-
@PJH said:
<shrug> must be just XP it happens in then.
oh spirit of confusion!
I did this on XP; I do not know if it's any different on Vista and have no 7 handy.
-
One of the troubles with resizable dialogs in Windows is last I checked, you had to reinvent the wheel and manually resize and move everything when your window is resized. Widgets are placed at pixel coordinates with pixel sizes. GTK on the other hand uses relative positioning similar to HTML elements, so it's pretty much automatic.
I'd hope some newer systems like .NET handle this for you...
-
@lolwtf said:
GTK on the other hand uses relative positioning similar to HTML elements
GTK's widget positioning is similar to HTML elements much like a monster truck is similar to a scooter. There's so much wrong with HTML element positioning I don't even know where to begin. Most of the time you end up with a weird hybrid between absolute and relative positioning, and pixel and em units. Crafting a truly working resizable interface in HTML requires a tremendous amount of work and in-depth knowledge about the CSS box model. In GTK you can just slap the containers and widgets in place with Glade and be done with it - the toolkit does the Right Thing™.
-
@lolwtf said:
I'd hope some newer systems like .NET handle this for you...
WinForms doesn't "handle it for you", but it gives you the tools you need to make it work quick and easy. That particular Windows dialog, alas, needs to run during Setup and probably Recovery Mode, so it almost certainly doesn't have WinForms as an option.
-
@Anonymouse said:
One of the most annoying non-resizable dialogs, IMHO, is the "Set Environment Variable" dialog. Ever tried to edit, say, a PATH variable of about a dozen entries in a text box control which shows you somewhere around 20-30 characters? Ugh!
+1 for frustration. I recently had to do this when my Oracle client was playing up. Most horrible dialog I've used in quite some time.
-
@Scarlet Manuka said:
@Anonymouse said:
Oracle users have no right to complain about terrible design - pariticularly on windows for OS features so outdated only Oracle users ever have to see them. Seriously, I didn't realize we still had an environment variables dialog.One of the most annoying non-resizable dialogs, IMHO, is the "Set Environment Variable" dialog. Ever tried to edit, say, a PATH variable of about a dozen entries in a text box control which shows you somewhere around 20-30 characters? Ugh!
+1 for frustration. I recently had to do this when my Oracle client was playing up. Most horrible dialog I've used in quite some time.And now that you've gone and pointed it out, I had to look - and I demand to know why the fuck all this modern software (particularly SDKs) isn't using the fucking registry for this shit.
-
@tdb said:
There's so much wrong with HTML element positioning I don't even know where to begin.
There's nothing wrong with it.
@tdb said:
Most of the time you end up with a weird hybrid between absolute and relative positioning
@tdb said:
in-depth knowledge about the CSS box model
It appears you end up with the former because you lack the latter. But that doesn't mean it's alll wrong.
I agree that HTML positioning and desktop widget positioning should not be compared as lightly as lolwtf did.
-
@dhromed said:
@tdb said:
There's so much wrong with HTML element positioning I don't even know where to begin.
There's nothing wrong with it.We've had this discussion. Yes there is, and you know it full-well.
-
@Weng said:
@Scarlet Manuka said:
@Anonymouse said:
Oracle users have no right to complain about terrible design - pariticularly on windows for OS features so outdated only Oracle users ever have to see them. Seriously, I didn't realize we still had an environment variables dialog.One of the most annoying non-resizable dialogs, IMHO, is the "Set Environment Variable" dialog. Ever tried to edit, say, a PATH variable of about a dozen entries in a text box control which shows you somewhere around 20-30 characters? Ugh!
+1 for frustration. I recently had to do this when my Oracle client was playing up. Most horrible dialog I've used in quite some time.And now that you've gone and pointed it out, I had to look - and I demand to know why the fuck all this modern software (particularly SDKs) isn't using the fucking registry for this shit.
You can also edit the file where those variables are stored, no need to deal with pesky dialog, linux style ;)
-
@blakeyrat said:
We've had this discussion. Yes there is, and you know it full-well.
There's tons of shit wrong with the HTML and CSS spec, but absolute/relative positioning isn't it.
-
@dhromed said:
@blakeyrat said:
We've had this discussion. Yes there is, and you know it full-well.
There's tons of shit wrong with the HTML and CSS spec, but absolute/relative positioning isn't it.
There is a huge problem with relative positioning! In every CSS positioning declaration, you have to scrutinize the possibilities to the obvious question of "relative to what?". The parent? The page? The available space? The space that the element would take up? Or could take up? Just what does "width: 100%" mean???
-
@Xyro said:
There is a huge problem with relative positioning! In every CSS positioning declaration, you have to scrutinize the possibilities to the obvious question of "relative to what?". The parent? The page? The available space? The space that the element would take up? Or could take up? Just what does "width: 100%" mean???
Are you serious? All those things are very well-defined and consistent across browsers. Flailing wildly doesn't make the system any less consistent.
A) absolute positioning is always relative to its first parent that is itself positioned position. In lieu of other elements, this is BODY.
B) relative positioning is always relative to where it would normally be without any positioning. It is relative to itself.
C) width 100% means "set the width of this element to the same computed value as its parent"
The only place where browsers and standards fail across the board with respect to positioning is layering. You have:
- source order
- positioning Y/N
- floating
- z-index
Browsers all seem to give these properties a different priority. In some situations, it's pretty tough to layer your elements right. Firefox tends to respond to z-index very well because z-index is a global thing, but in IE8- you have to analyze the family structure, because apparently z-index is sibling-specific.
I think (unsupported claims ahead) IE6 gave float the near-highest priority, so all your positioned elements and z-indexes be damned: it floats, it gets to be on top.
-
@dhromed said:
Are you serious? All those things are very well-defined and consistent across browsers. Flailing wildly doesn't make the system any less consistent.
Yeah, then you put in a "border: 3px solid black" and suddenly things are wrapping around to the next line, but why!?!? Why the fuck in a sane world would adding a border to an element change the position of the element?
Look, I'm sure the "rules" are strictly defined somewhere, and I'm sure that browsers are getting them right. The real problem is that there's too many complex interactions that it can't fit in the goddamn human skull. I think it's safe to say most CSS users spend most of their time guessing and checking to get the layout right-- if it were a good layout language, there would be no guesswork involved.
Microsoft, who implemented the box model in a somewhat sane way (meaning, the example in my first sentence wouldn't happen in IE6), they were "punished" by the W3C declaring that they had implemented the woefully vague "specification" incorrectly. Despite the fact that Microsoft's implementation made more fucking sense. (See also: Event.Button, (obj).innerText, document.readyState, basically everything IE did in regards to the web was significantly better-designed than the spec's way of doing the same thing.)
But as I said above, we've been over this before.
-
@dhromed said:
A) absolute positioning is always relative to its first parent that is itself positioned position. In lieu of other elements, this is BODY.
Right, so, let's say you wanted to absolutely position something in the top right corner of the page (but not fixed). Can you do that? Well ... you'd have to check through all the parents' positioning, too. It's still relative! So you still have to scrutinize "relative to what?". Kind of like the same problem of z-index ordering in IE: they're not global!
@dhromed said:
B) relative positioning is always relative to where it would normally be without any positioning. It is relative to itself.
Hmm, I was trying to reproduce an issue I previously had with some combination of floating and display and relative positions, but I can't seem to hit it. Maybe it was an old bug in the browser and/or my thinking.
@dhromed said:
C) width 100% means "set the width of this element to the same computed value as its parent"
Only if display is block or inline-block, or inline with absolute or fixed positioning, but not inline with static or relative positioning. And table cell displays are all wonky. And then there is overflow and margins. 100% width plus margins always comes out askew.
Here, try this:<html> <head> <style type="text/css"> div { position: relative; /* If this shows up without the colon, blame CS */ top: 10px; margin: 1em; width: 100%; } #d1 { background-color: red; } #d2 { background-color: blue; } </style> </head> <body> <div id="d1"> <div id="d2">foo</div> </div> </body> </html>What I would naively guess with such a declaration is a white page with a red banner and blue banner. The red banner would be margined by 1em from the top, left, and right of the page. Within this red banner would be a blue banner, with a 1em margin to the top, left, right, and bottom from the red banner, except the blue banner would also be offset 10px down. Because the blue banner has a margin within the red banner, the red banner should be larger by 2 em for each dimension.
Instead, what I see is a white page with margins at the top and left, the red banner ending at the window's right side, and a a long blue rectangle of the same height extending past the right of the window. The blue rectangle ends abruptly with no margin.
Please explain to me how this is supposed to make sense.
-
Dear Xyro, your problems have nothing to do with positioning, but with margins and box-sizing, both of which have problems.
@Xyro said:
What I would naively guess with such a declaration is a white page with a red banner and blue banner.
Ok good so far.
@Xyro said:
The red banner would be margined by 1em from the top, left, and right of the page
Plus 10px for your position:relative;
@Xyro said:
Within this red banner would be a blue banner, with a 1em margin to the top, left, right, and bottom from the red banner. Because the blue banner has a margin within the red banner, the red banner should be larger by 2 em for each dimension.
Nope. You got bitten by collapsing and overflowing margins. That's okay. It's a shitty feature. I hate it. You expected the red banner to expand vertically with the blue banner's margins, but alas, that is not how it works.
-
@blakeyrat said:
Yeah, then you put in a "border: 3px solid black" and suddenly things are wrapping around to the next line, but why!?!? Why the fuck in a sane world would adding a border to an element change the position of the element?
Ok, so the only alternative is that borders simply overlap their surroundings when they expand, which:
A) creates even more ambiguous layering complexity to define. Does border trump source order? z-index? has-position?
B)how does it interact with margins? Do margins grow form the borderbox or paddingbox? Either way you're forcing me to add margins that are as wide as my border in order to prevent the border from overlapping neighbouring elements. I already constantly recalculate fixed widths when I add padding and it sucks shit.*
Things are not as obvious as you think.
*) Padding, imho, should not increase the box width. But at the same time, half the use cases are where you want to be able to trust that width:100px is in fact consistently 100px and not "100px and hope you didn't forget to mentally subtract the padding!" So I see the point in making padding increase the box. In fact I'm going to investigate if I can set the padding-box on or off for a given element, so that I can make padding behave as I want to on-demand.
Edit.
Welp, almost. Browser support is flakey. Experiments needed, I guess.
-
:(
Thanks for the insight, dhromed.
-
Microsoft was criticised for that because it was DIFFERENT to what the other browsers do. You can complain all day about the various WTFery in HTML and CSS, believe me, I've made DeviantArt journal themes, joomla themes, wordpress templates, and straight up raw pages, and I have beaten CSS down more ways than I'd like to explain. But as much as it is trial and error, it is 99% of the time consistent. What Microsoft did was change the implementation (admittedly to something that did make more sense) but by doing so began the tradition of having to code 50 extra lines of code into a website to compensate for the browser with the biggest market share not rendering pages the same as all the others. So your options were to comply with the W3C, comply with Microsoft, or ass your way around with a lot of extra code to make it work for both. And that's a no-brain decision for most business owners, especially when those groups represent essentially half and half of the internet community. You make it work.
-
-
@Master Chief said:
So your options were to comply with the W3C, comply with Microsoft, or ass your way around with a lot of extra code to make it work for both. And that's a no-brain decision for most business owners, especially when those groups represent essentially half and half of the internet community. You make it work.
This is why we hate the W3C.
-
@Master Chief said:
Microsoft was criticised for that because it was DIFFERENT to what the other browsers do.
Nobody's denying that it was different.
The problem was, at the time Microsoft began work on CSS, the spec was so vague that Microsoft's interpretation was just as correct as Netscape's. That's how shitty the spec was. Microsoft's implementation was different; it was also correct.
@Master Chief said:
What Microsoft did was change the implementation (admittedly to something that did make more sense)
Nope; they coded to an incredibly vague spec to the best of their ability.
@Master Chief said:
And that's a no-brain decision for most business owners, especially when those groups represent essentially half and half of the internet community. You make it work.
One thing I frequently complain about web developers is how fucking lazy and whiny they are. Yes, it's slightly hard to get a layout to work in both Chrome 12 and IE6. Cry more, baby. It's still an order of magnitude easier than almost every other problem in IT ever. Web developers are mounting huge campaigns whining about IE6, meanwhile there's still no easy to way to make a cross-platform GUI program.
And while IE6 was harder to code, and wasn't as slick-looking as the newer, shinier, browsers, it's a flat-out lie saying that it was "holding back the web"-- tell me, what feature did IE6 lack that held-back your website? XMLHttpRequest? Real-time DOM manipulation? Oh what's that? You can't put your money where your mouth is? Then shut up, whiny web developer person.
/flame
-
@dhromed said:
Things are not as obvious as you think.
That's pretty much my exact point, CSS isn't even remotely close to being in the same continent as "obvious", which is why it's so fucking hard to use.
-
@blakeyrat said:
meanwhile there's still no easy to way to make a cross-platform GUI program.
Sure there is! You just have to host it in the browser...
-
@blakeyrat said:
That's pretty much my exact point, CSS isn't even remotely close to being in the same continent as "obvious", which is why it's so fucking hard to use.
I guess I agree on specific parts of the CSS spec. It has significantly more arbitrariness* than one would expect. But it's not impossible, and it's not unlearnable by a long shot.
I think the original discussion was specifically about whether the positioning bit of CSS was tricky, crap or otherwise vague, and it is none of those things, but we can drop it if you want. :)
*) which is where the committee basically says "ey, let's do it this way and not think about it too hard. Man, I'm famished. Who wants lunch?".
-
@dhromed said:
I think the original discussion was specifically about whether the positioning bit of CSS was tricky, crap or otherwise vague, and it is none of those things, but we can drop it if you want. :)
The original point was that creating layouts using HTML and CSS is much more tricky than doing the same using a GUI widget toolkit. Besides the coordinates of the upper left corner of an element, this also includes dimensions and other properties which may affect the layout of the widget and its children. If you want to disagree with this, I'll happily throw some challenges your way.
-
@blakeyrat said:
The problem was, at the time Microsoft began work on CSS, the spec was so vague that Microsoft's interpretation was just as correct as Netscape's. That's how shitty the spec was. Microsoft's implementation was different; it was also correct.
Nope; they coded to an incredibly vague spec to the best of their ability.
Tomayto, Tomahto. Impossible to really know who was right, because as you say, the standards were indeed shit. This is no longer the case (mostly). The fact of the matter is that just about everything that worked on Firefox, Opera, and Netscape would bork under IE6, because Microsoft refused to do proper testing.
@blakeyrat said:
One thing I frequently complain about web developers is how fucking lazy and whiny they are. Yes, it's slightly hard to get a layout to work in both Chrome 12 and IE6. Cry more, baby. It's still an order of magnitude easier than almost every other problem in IT ever. Web developers are mounting huge campaigns whining about IE6, meanwhile there's still no easy to way to make a cross-platform GUI program.
I don't care in the slightest if you want me to bill you (the client) all the extra time to test and make sure the site works on all the uncooperative browsers out there. I am not whining, it's part of the job. I'm simply stating that Microsoft's complete lack of coherence with every other browser only served to make my job take longer. It served no other purpose whatsoever.
@blakeyrat said:
And while IE6 was harder to code, and wasn't as slick-looking as the newer, shinier, browsers, it's a flat-out lie saying that it was "holding back the web"-- tell me, what feature did IE6 lack that held-back your website? XMLHttpRequest? Real-time DOM manipulation? Oh what's that? You can't put your money where your mouth is? Then shut up, whiny web developer person.
/flame
When did I say anything about that you bloody lunatic? IE6 didn't hold back anything, except some users from enjoying websites that didn't have the money or patience to make IE cooperate.
-
@Master Chief said:
Tomayto, Tomahto. Impossible to really know who was right, because as you say, the standards were indeed shit.
They were both right. Which was my point, which obviously didn't get made...
That said, Netscape's implementation was closer to the intention of the spec. But both implementations were equally right at the time-- the spec didn't get clarified until after IE had already shipped with their "wrong" implementation.
@Master Chief said:
The fact of the matter is that just about everything that worked on Firefox, Opera, and Netscape would bork under IE6, because Microsoft refused to do proper testing.
Microsoft's priority was backwards-compatibility with IE, not cross-compatibility with Firefox/Opera/et al. If Microsoft had prioritized cross-compatibility, they would have written a cross-compatible browser. "Proper testing" has nothing to do with it.
@Master Chief said:
I'm simply stating that Microsoft's complete lack of coherence with every other browser only served to make my job take longer. It served no other purpose whatsoever.
Sure it did; to say otherwise is not only extremely naive, but assumes Microsoft is staffed by morons.
-
@Weng said:
@Scarlet Manuka said:
What makes you think Oracle users don't complain about Oracle software design flaws too? Indeed, we have a whole sub-forum dedicated to the purpose. It's not as if I have a choice about using Oracle products anyway.@Anonymouse said:
Oracle users have no right to complain about terrible design - pariticularly on windows for OS features so outdated only Oracle users ever have to see them. Seriously, I didn't realize we still had an environment variables dialog.One of the most annoying non-resizable dialogs, IMHO, is the "Set Environment Variable" dialog. Ever tried to edit, say, a PATH variable of about a dozen entries in a text box control which shows you somewhere around 20-30 characters? Ugh!
+1 for frustration. I recently had to do this when my Oracle client was playing up. Most horrible dialog I've used in quite some time.And now that you've gone and pointed it out, I had to look - and I demand to know why the fuck all this modern software (particularly SDKs) isn't using the fucking registry for this shit.
As for using the registry - Oracle does, in fact, use the registry, and claims that you don't actually need to set ORACLE_HOME. However, while some things work this way, others don't; pick just about any TNS error you care to name and look for help on the net and you're likely to see the first suggestion being "Make sure ORACLE_HOME is set properly..."
So yeah, Oracle is one of the real WTFs. [url=http://forums.thedailywtf.com/forums/t/24745.aspx]I'm aware of this.[/url] That doesn't mean the Environment Variables dialog in Windows can't also be one.
-
@MrMartijn said:
yeah but why not a back button in the button space (the gray bar) like all sane software does.
and why can linux make every single piece of hardware work with a 8mb kernel image, but windows still needs downloads and disks...Hahaha, jesus christ dude - comedy gold.
"Dude, trolling requires subtlety." - someone on this forum (sorry, forgot)
