Java's Applet layout tools.



  •  Yeah, I hate them. They don't work how I think they should and are extremely limited. What's wrong with just assigning each of the GUI objects an X,Y position and being done with it? GridLayout is the only one that's even remotely predictable and useful and that's only because it makes a decent amount of sense. The others (and even GridLayout to a degree) feel like tools an overzealous and under experienced novice decided to create one weekend to "make GUIs easier."

     

    If I ever use Java again when I'm out of school, I'm writing my own damn applet GUI library and WYSIWYG editor that uses X,Y coordinants and the keyboard and mouse will be accessible with simple Input.isLeftButtonPressed() like calls. I can't believe Java doesn't have anything more convenient and orderly for programmers to use than listeners. They're great for GUI buttons, but blow chunks for mouse and keyboard input.



  •  Sure, but you do realize that x,y doesn't really work?

     After all, some use 1280x1024, some use 1024x600, and some 800x600 (actually, I use all of the above). If you use x,y, you have to fit to a minimum that immediately becomes your maximum.

     The point of the Java layouts (actually, they predate Java, TCL/TK uses the same idea), is that you specify the positional relationships, and the layout object fits it. The top layout object is then aware of the actual window or screen size.

     Using x,y does work well, as long as you never have to decrease the size of your display.

    All of which means - where is the WTF? Before complaining, try thinking about the problem a bit, anyway.

    Or... the real WTF is that Evolution preferences screen is deeper than 600 pixels. Even though it doesn't have to be. Causes me all sorts of pain on my hardened laptop (only 800x600) and on my netbook (1024x600). Not everyone HAS 768 vertical pixels.



  • @ratboy667 said:

     Or... the real WTF is that Evolution preferences screen is deeper than 600 pixels. Even though it doesn't have to be. Causes me all sorts of pain on my hardened laptop (only 800x600) and on my netbook (1024x600). Not everyone HAS 768 vertical pixels.

    Of course it has to be deeper than 600 pixels.  How could it annoy the crap out of you otherwise



  • @JohnWestMinor said:

    If I ever use Java again when I'm out of school, I'm writing my own damn applet GUI library and WYSIWYG editor

    Netbeans does this



  •  I suppose I ought to research the tools more before complaining, but my teacher wanted us to do the layout programming by hand and it drove me nuts.

     

    And I still think X,Y could work if the X,Y positions are actually based on a percentage of the size of the screen. I know that's KIND of what the layouts do, but they don't do it well enough.

     Example, I develop on a 500x500 window. All of the X,Y positions will be actualX= X*actualWindowX/500; actualY=Y*actualWindowY/500; Should work with little pain if I plan the draw and mouseEnter methods well enough, which just means passing the actualX and actualY and actualXSize and actualYSize variables in instead of the 500x500 based variables. Sure, it's more overhead and Netbeans might do everything I want without hassle, but it'd be an interesting project.

    NIH is only useless when not done for research or improvement, but rather simple implementation.



  • @JohnWestMinor said:

    Yeah, I hate them. They don't work how I think they should and are extremely limited. What's wrong with just assigning each of the GUI objects an X,Y position and being done with it? GridLayout is the only one that's even remotely predictable and useful and that's only because it makes a decent amount of sense. The others (and even GridLayout to a degree) feel like tools an overzealous and under experienced novice decided to create one weekend to "make GUIs easier."


    Everything is wrong with just assigning GUI objects an X,Y position. It's OK if you have one screen size, one font and carefully check that all your localizations will fit, but otherwise you need something to ensure your texts will fit on the widgets. None of that is the case in applets. A decent GUI library (like Gtk or Qt) makes it easy to use layouts and discourage fixed offsets. Now why most of the Java GUI stuff is anything but decent is another matter (and WTF).

    @JohnWestMinor said:

    If I ever use Java again when I'm out of school, I'm writing my own damn applet GUI library and WYSIWYG editor that uses X,Y coordinants and the keyboard and mouse will be accessible with simple Input.isLeftButtonPressed() like calls. I can't believe Java doesn't have anything more convenient and orderly for programmers to use than listeners. They're great for GUI buttons, but blow chunks for mouse and keyboard input.


    Simple Input.isLeftButtonPressed() will make the user curse you to hell and kill off the browser page, because the damned applet takes all the CPU power. The main problem with listeners in Java is that it takes quite a bit of typing to make them (compared to C++, C#, Python, Perl, Ruby, EcmaScript, Lua ... that all have some kind of "function object" and simple way to wrap a method with it's invocant into one).



  • @JohnWestMinor said:

    And I still think X,Y could work if the X,Y positions are actually based on a percentage of the size of the screen. I know that's KIND of what the layouts do, but they don't do it well enough.

     

     Pick any program and you'll see that this does not really work.

    For example Firefox (which is what I see now). If everything was in percentages, the page (and tab bar etc.) would move down the window when scaling. It doesn't do that, and it would be totally crazy to do, as the navigation takes constant space.

    The point of GridLayout is that there are parts that should scale (multi-line inputs, scrollable lists) and parts that shouldn't (single-line inputs, buttons).



  • It is possible to create Java GUIs without any layout managers. But you will soon find yourself writing lots of layout code by hand if your GUI gets more difficult.

    The layout that I use now when making Java programs (not very often) is GroupLayout -- it allows creating very complex layouts by following a few simple rules. You can use the GUI builder in NetBeans that uses GroupLayout, or you could learn how to write it by hand. The only downside is that it needs Java 1.6.



  • @JohnWestMinor said:


    If I ever use Java again when I'm out of school, I'm writing my own damn applet GUI library and WYSIWYG editor that uses X,Y coordinants and the keyboard and mouse will be accessible with simple Input.isLeftButtonPressed() like calls. I can't believe Java doesn't have anything more convenient and orderly for programmers to use than listeners. They're great for GUI buttons, but blow chunks for mouse and keyboard input.

     

     

    Typical WTF, trying to rewrite a complete library just because you have not finished learning the existing one and before mastering the language. Open your books and learn. There is no reason to rewrite such libraries and this forum is not the place to teach you the basics of that language.



  • @JohnWestMinor said:

    and I still think X,Y could work if the X,Y positions are actually based on a percentage of the size of the screen. I know that's KIND of what the layouts do, but they don't do it well enough.
    I've seen code apps which work exactly like this, but they all suffer from a few fatal flaws: In the first case, you can maximise the window but none of the controls change position or size (so kinda useless) and in the second case, the control move position but do not scale (so you have lots of empty space and still no real benefit of maximising the window). So you have to write a "OnResize" event that gets given the old and new width/height of the window and reposition/rescale all the gui elements yourself, which is far worse than throwing them in layout containers and letting the parents resize all there childs. 

    Like other people have said, listeners are pretty essential in Java. You don't want your script running constantly and sucking up the processor power, you just want to be notified when something happens, which is how all Windows, Linux and Mac apps work. 



  • @Mole said:

    So you have to write a "OnResize" event that gets given the old and new width/height of the window and reposition/rescale all the gui elements yourself, which is far worse than throwing them in layout containers and letting the parents resize all there childs.

    If you are a student, it's not a bad idea to try to do that at least once. Just like the linked lists that you have to write. But the lesson learned here should be not how to do it yourself by hand but to learn and use the layout managers that someone has already written, tested and documented for you to use.

    It is also useful experience for working with GUIs that don't have layout managers.



  • @tchize said:

    Typical WTF, trying to rewrite a complete library just because you have not finished learning the existing one and before mastering the language.
     

     +1

     May I add, being an old fart and having seen this many many times, that this WTF is usually committed by people who are pretty smart but not very wise.


  • Trolleybus Mechanic

    @JohnWestMinor said:

    The others (and even GridLayout to a degree) feel like tools an overzealous and under experienced novice decided to create one weekend to "make GUIs easier."

    All this has happened before.

    @JohnWestMinor said:

    If I ever use Java again when I'm out of school, I'm writing my own damn applet GUI library and WYSIWYG editor

     And will happen again.

     



  • @Lorne Kates said:

    @JohnWestMinor said:

    The others (and even GridLayout to a degree) feel like tools an overzealous and under experienced novice decided to create one weekend to "make GUIs easier."

    All this has happened before.

    @JohnWestMinor said:

    If I ever use Java again when I'm out of school, I'm writing my own damn applet GUI library and WYSIWYG editor

     And will happen again.

    And TDWTF will be there...



  • @bstorer said:

    And TDWTF will be there...
     

    And we will bring Eric.



  • @dhromed said:

    @bstorer said:

    And TDWTF will be there...
     

    And we will bring Eric.

    Dick is the diminutive form of Richard, not Eric.



  • The swing layout system is not THAT bad, but and semantic of the 3 different widths a component may have is complicated and not that well designed/documented. But once you learn it it's not that difficult. (And the javadoc layout documentation sucks).

    The reason you can't just use x/y is: Imagine you have a bar with 5 buttons where each button have a text. And you want to put them next to each other. You can't give x/y because you don't want the buttons to scale, you want them to have their "natural" size, which is based on the size of the text in the button.

    I think the best way to do layout is just using nested box layouts. It is simply and can do almost anything you need.

     



  • @morbiuswilters said:

    Dick is the diminutive form of Richard, not Eric.
     

    Dear god! I was under the impression that Eric and Richard shared a common ancestor, but a quick Wiki-ing does not support this.

    We should call Richard. Eric's a dick anyway.



  • Maybe the poster should look at Qt: It allows you to both place buttons wherever you wish (X,Y if you so desire) and use a full complement of layout tools. People seem to start with the former, notice the restrictions and problems and then upgrade to the later. 

    Java has Qt bindings, try it out. 



  • @morbiuswilters said:

    @dhromed said:

    @bstorer said:

    And TDWTF will be there...
     

    And we will bring Eric.

    Dick is the diminutive form of Richard, not Eric.

    Yeah, but Eric has a diminutive form of dick.


  • Sounds like you'd like WinForms. Personally, I'm extremely grateful that I'm using WPF.




    Mostly.



  • http://www.miglayout.com/ should be able to do whatever you want.



  •  I like both actually. I see WPF mostly as winforms++

     The main reason I don't use it yet is because Mono doesn't support it (yet) and most of the small tools I write (in C#) "need" to run on that (not really need, just that I and others who use them frequently work on linux and it would be a pain to switch over constantly).



  •  Just use [url=http://www.eclipse.org/swt/]SWT[/url]. It's a bit of a pain to figure out how to configure everything to still be multi-OS (if you care) but after that I find it very usefull and much prettier.
    Eclipse also has 2 designer plugins (I forget their names) that don't generate that but-ugly code like NetBeans.

    Someone told me that you can even just use CSS with SWT, dunno if you should be happy with that but hey, it's easy alright :)

     

    I'd prefer WPF anytime though, and even WinForms is 10x better than Swing or Awt...



  • @Bulb said:

    @JohnWestMinor said:

    If I ever use Java again when I'm out of school, I'm writing my own damn applet GUI library and WYSIWYG editor that uses X,Y coordinants and the keyboard and mouse will be accessible with simple Input.isLeftButtonPressed() like calls. I can't believe Java doesn't have anything more convenient and orderly for programmers to use than listeners. They're great for GUI buttons, but blow chunks for mouse and keyboard input.

    Simple Input.isLeftButtonPressed() will make the user curse you to hell and kill off the browser page, because the damned applet takes all the CPU power. The main problem with listeners in Java is that it takes quite a bit of typing to make them (compared to C++, C#, Python, Perl, Ruby, EcmaScript, Lua ... that all have some kind of "function object" and simple way to wrap a method with it's invocant into one).

     

    Eh? I'm calling bullshit on that. I wrote the classes neccesary to make Input.isLeftButtonPressed() work and I just had the listener update static variables in a class named Input with all static instance members, accessors and mutators. That won't take up too much more CPU power than just the listener itself.

    The only thing that I would consider even halfway suspect about it is my use of boolean[] asciiFlag=new boolean[128]; to handle all the keys with ascii codes, but I felt it would be messier and harder to maintain if I culled it down to only the neccesary keys, which would only save about 50-70 bits of memory if any at all with the extra bulk in the methods to handle the jumps in the ordering.

     

     @bstorer said:

    @Lorne Kates said:

    [quote user="JohnWestMinor"]The others (and even GridLayout to a degree) feel like tools an overzealous and under experienced novice decided to create one weekend to "make GUIs easier."

    All this has happened before.

    @JohnWestMinor said:

    If I ever use Java again when I'm out of school, I'm writing my own damn applet GUI library and WYSIWYG editor

     And will happen again.

    And TDWTF will be there...

    [/quote]

    Yeah, yeah, I get it, I was a fool to spout off about this before learning everything about layouts. But like I said earlier, NIH is only bad when it's intended for implementation and not research or potential improvement. I certainly wouldn't force my own personal libraries on any place I worked unless there were no equivilants available that had been well documented and tested. Only other fellow hobbyists will get to experience the horror of my abominations! BWAHAHAHAHAHAHAHAHAHAHA!!!

     



  • @JohnWestMinor said:

    Example, I develop on a 500x500 window. All of the X,Y positions will be actualX= X*actualWindowX/500; actualY=Y*actualWindowY/500; Should work with little pain if I plan the draw and mouseEnter methods well enough, which just means passing the actualX and actualY and actualXSize and actualYSize variables in instead of the 500x500 based variables.

    That doesn't work. Say you made all the buttons the same size so that they look nice. If a vision-impaired user turns the font size up but the buttons with twice as much text stay the same size as the buttons with half as much, the buttons will be unusable.  The right way is for you to specify the relationships between objects, not their positions.



  •  Then I assign them X,Y positions in containers, ALMOST similar to the layouts.



  • @JohnWestMinor said:

    Eh? I'm calling bullshit on that. I wrote the classes neccesary to make Input.isLeftButtonPressed() work and I just had the listener update static variables in a class named Input with all static instance members, accessors and mutators. That won't take up too much more CPU power than just the listener itself.
    So you wrote the listener code anyway, so why not just use that rather than another abstraction?

    Secondly, how is your non-listener code going to check Input.isLeftButtonPressed? Listeners make your code event driven and so your code runs only when needed (when an event occurs)



  • @JohnWestMinor said:

    NIH is only bad when it's intended for implementation and not research or potential improvement.
     

    +1

    I invent shit all the time, make it work reasonably, and then throw it away in favour of the mature product someone else has already made. A prime example of this is a sliding animation with acceleration/deceleration* of a small background image of a series of icons, using javascript. It was a smooth and delightful thing to behold (on my machine, at least ^H^H). 6 months later, I walked into a bar and met jQuery with her full, round and firm .animate()s. I fell in love instantly and haven't looked back, because her luscious bosom is much better than my boob attempt at sinusoidal motion, and it made me respect the code that powered that simple method.

     

    *) it lopped those celery bits right off!



  • @Mole said:

    @JohnWestMinor said:

    Eh? I'm calling bullshit on that. I wrote the classes neccesary to make Input.isLeftButtonPressed() work and I just had the listener update static variables in a class named Input with all static instance members, accessors and mutators. That won't take up too much more CPU power than just the listener itself.
    So you wrote the listener code anyway, so why not just use that rather than another abstraction?

    Secondly, how is your non-listener code going to check Input.isLeftButtonPressed? Listeners make your code event driven and so your code runs only when needed (when an event occurs)

     

    if(Input.isLeftButtonPressed)

    {

    //Do stuff

    }

     

    Well, keep in mind I'm talking about a more complex interface design than just "push onscreen button, do that." I.E, not just form applets (I have no problem with listeners for onscreen buttons). Considering that, having a step timer to call a general update method for all updateable objects and then letting them check the static Input.*() methods as needed is far easier. My system is also especially useful for complex button presses, like ctrl+a+s as all the neccesary variables are built into the Input class.

     

    Now, I certainly see the angle you guys are coming from and where my way of thinking doesn't mesh. After all, I got interested in programming from a video game perspective, not an event driven or applet/application driven perspective.



  • I've pretty much given up on hand coding Java Swing. Netbeans is nice (think it was called Matisse last time I used it) but the layouts it makes suffer from the same sorts of portability and maintainability problems as Dreamweaver HTML.

    Groovy SwingBuilder is what I use now for Java Swing layouts...it can be as simple as:

    table {

    tr {

    td {

    myLabelWidget

    } td {

    myFieldWidget

    }

    }

    }



  • @JohnWestMinor said:

    Well, keep in mind I'm talking about a more complex interface design than just "push onscreen button, do that." I.E, not just form applets (I have no problem with listeners for onscreen buttons). Considering that, having a step timer to call a general update method for all updateable objects and then letting them check the static Input.*() methods as needed is far easier. My system is also especially useful for complex button presses, like ctrl+a+s as all the neccesary variables are built into the Input class.

    The right way to do this is to have listeners that set application-specific variables on the event dispatch thread, and then have the update call on the timer thread check those variables, do its processing, and set other variables which are in turn used to render back on the EDT. No singletons with huge arrays of key data necessary.



  • Seems like having the Input singleton would be easier in the long run and keep applets from having to recreate what would basically amount to the same thing over and over again (you also will have extremely straightforward and easy to understand plumbing). You'll have some excess, but memory is cheap these days, even on older computers.Other than that the implementation you describe is almost identical to mine.

    In other words, if I'm making a set of tools, I want them all to follow the same basic rules of design, even if they aren't the best ones, so that anyone who has to maintain the code knows what to expect. Having those elements of my designs abstracted out for immediate reuse means that anyone dealing with my code only needs to learn how I do things once because I've only created them once and they can all be studied separate from my programs.

     

    Of course, I know competent companies have specific styles and methodologies that are different from my own that they enforce for that same reason. I'm just defending my own as being valid.



  • Considering every Java GUI application ends up looking like this, I think the best advice is "don't use Java for GUI apps unless there is literally no other choice."

    (Yes, that is a list of status messages in the form of a drop-down menu!)



  • @blakeyrat said:

    Considering every Java GUI application ends up looking like this, I think the best advice is "don't use Java for GUI apps unless there is literally no other choice."

    (Yes, that is a list of status messages in the form of a drop-down menu!)

     

    Well that's not really Java/Swing's fault, it's just stupid coding. And the gui itselfs looks quite OK methinks. It's quite possible to create nice GUI's in Java (especially with Swing), it just isn't easy.



  • @dtech said:

    Well that's not really Java/Swing's fault, it's just stupid coding. And the gui itselfs looks quite OK methinks. It's quite possible to create nice GUI's in Java (especially with Swing), it just isn't easy.
     

    It might be possible, I concede that. I've never seen one.

    But you seriously think that looks "quite OK?"

    What about the horrible waste of whitespace?

    What about the mis-matched colors below the wrongly-shaped tabs? (Which, BTW, didn't match my theme colors to-boot-- the theme is supposed to put a blueish shade in highlighted tabs.)

    The disabled "cancel queue" button is completely wrong... images in disabled buttons are supposed to be dimmed, but not turned greyscale like that.

    The squished-up icon? That looks ok?

    The fact that shrinking the main (background, in that screenshot) window, when scaled down vertically, simple cuts-off the upload and download icons? (The folders with green arrows on them.)

    "TransferQueue" as a menu item? "The OS doesn't allow multi-word menu titles, so let's just camel-case it!"

    And what really got me started on this all is that the app doesn't even alphabetize correctly. I can't upload a screenshot of that without breaking my NDA, but it alphabetizes like: A-Za-z. (That is, the file "Zygote.txt" comes *before* "absinthe.txt".)

    Some of these things are undoubtedly the result of "stupid coding" as you say. (I skipped some things that are obviously stupid coding.) But the fact that you think this GUI looks "quite OK" also speaks to something else I've noticed recently: people who write Java apps are simply incapable of judging the quality of a GUI. (Thus, they think Java is capable of making a good GUI.)



  • @blakeyrat said:

    And what really got me started on this all is that the app doesn't even alphabetize correctly. I can't upload a screenshot of that without breaking my NDA, but it alphabetizes like: A-Za-z. (That is, the file "Zygote.txt" comes *before* "absinthe.txt".)
    It looks OK to me too, to be honest. Nothing immediately jumped out at me and said "WTF!".

    The reason for A-Za-z is probably due to lazy coding, as 'A' is less than 'a'  in the ASCII character set.



  • @blakeyrat said:

    (Yes, that is a list of status messages in the form of a drop-down menu!)

     

    This has been a feature of the Lotus Notes email inbox for a long time, leading me to think that the creator of this "Bucket Explorer" drew his inspiration from that wonder of wonders.

    The thought that anyone could look at any part of the Notes interface and think 'hey, that's a good idea' is simply terrifying.



  • @Someone You Know said:

    @blakeyrat said:

    (Yes, that is a list of status messages in the form of a drop-down menu!)

     

    This has been a feature of the Lotus Notes email inbox for a long time, leading me to think that the creator of this "Bucket Explorer" drew his inspiration from that wonder of wonders.

    The thought that anyone could look at any part of the Notes interface and think 'hey, that's a good idea' is simply terrifying.

     

    @blakeyrat said:

    But the fact that you think this GUI looks "quite OK" also speaks to something else I've noticed recently: people who write Java apps are simply incapable of judging the quality of a GUI. (Thus, they think Java is capable of making a good GUI.)

    Heheheheheh, I agree on both accounts. I haven't seen a Java UI yet that looks good. Some are mostly usable, but that's about it.

     x,y placement, with some OnResize handlers have their limitations, and have to mimic parts of what comes naturally with layout managers, but still often manage to do better than what I've seen especially Swing do.

    In an x,y placement UI you might get scroll bars if the window gets below a certain size, in Swing UI elements often just disappear with no way to get to them any more.

    Not to mention that most apps look like they're from 1993 16 color windows 3.1, or 256 color unix Xterms.

    Layout managers, if done well, can help a programmer, especially on issues like internationalization, but if done badly often create a bigger mess than simple x,y placement.

    When part of your UI is a bitmap image, then x,y placement can even be essential.



  • @RogerWilco said:

    When part of your UI is a bitmap image, then x,y placement can even be essential. you might consider a bullet through the brain
     

    FTFY



  • @Mole said:

    The reason for A-Za-z is probably due to lazy coding, as 'A' is less than 'a'  in the ASCII character set.
     

    Yah I concede that, but it's kind of a WTF to alphabetize in ASCII order when it's actually *easier* to alphabetize correctly. (Oh please God tell me it's easier to alphabetize correctly in Java?!)

    @Mole said:

    It looks OK to me too, to be honest. Nothing immediately jumped out at me and said "WTF!".

    But but... it's just... so... but... how!? It's not just wrong in the way Firefox is wrong in Windows Vista (which is subtle and hard to notice), this app is obviously, blatantly, eggregiously wrong. And hell, I'm not even criticizing some stuff, like the incorrect fonts. (I'm not much of a font-snob, so wrong fonts don't bother me as much as some people.)

    Take the wrong tabs. It's not like the Aero themes are rare, they're like the default theme on 40%+ of computers. Of course, those tabs would be wrong in XP's default theme, too! So this app is completely wrong on something close to 80% of the computers sold since 2002. And it's not like they're wrong because they're using the OS X tab style in Windows... they're just wrong.

    I just... can't wrap my head around anybody saying that that UI looks ok. Brain... boggling!

    How can anybody look at that thing and say, "this meets our quality expectations! Ready to ship!" How could the engineers just not give a flying shit to such a level?



  • @blakeyrat said:

    Take the wrong tabs. It's not like the Aero themes are rare, they're like the default theme on 40%+ of computers. Of course, those tabs would be wrong in XP's default theme, too! So this app is completely wrong on something close to 80% of the computers sold since 2002. And it's not like they're wrong because they're using the OS X tab style in Windows... they're just wrong.
    Given that using OS's native controls seems to be more an exception than the rule with Windows applications lately, the application really doesn't really look that out of place...



  • @ender said:

    @blakeyrat said:
    Take the wrong tabs. It's not like the Aero themes are rare, they're like the default theme on 40%+ of computers. Of course, those tabs would be wrong in XP's default theme, too! So this app is completely wrong on something close to 80% of the computers sold since 2002. And it's not like they're wrong because they're using the OS X tab style in Windows... they're just wrong.
    Given that using OS's native controls seems to be more an exception than the rule with Windows applications lately, the application really doesn't really look that out of place...

    Sadly true, especially since Adobe went off the deep-end.

    I have nothing against custom controls if they work. Firefox, my "good" example, uses custom controls, doesn't look (very) wrong, and works with tablet and speech recognition input. These Java tabs do none of those things.



  • I really find the Java Layout Manager to be very unintuitive. Also when using Win Forms I almost always use specific X and Y coordinates to place elements and never had any problems with different screen resolutions. I do always test my applications on multiple resolutions (currently ranging from 800x600 as lowest and 1680x1050 as highest). Also I always use the anchor properties of elements so the elements get resized automatically when necesarry.

    PS. In a past Java project I used the RiverLayout Layout Manager. Not really sure any more how it works but I was quite content with it at the time.



  • @pbean said:

    I really find the Java Layout Manager to be very unintuitive. Also when using Win Forms I almost always use specific X and Y coordinates to place elements and never had any problems with different screen resolutions. I do always test my applications on multiple resolutions (currently ranging from 800x600 as lowest and 1680x1050 as highest). Also I always use the anchor properties of elements so the elements get resized automatically when necesarry.
    Do you test with different DPI settings? Because just using different resolutions has zero effect on the widgets (well, unless the resolution is too low), but different DPI settings break most programs that rely on simple (X,Y) positioning.



  • @ender said:

    Do you test with different DPI settings? Because just using different resolutions has zero effect on the widgets (well, unless the resolution is too low), but different DPI settings break most programs that rely on simple (X,Y) positioning.
     

    XP-style DPI changes can break layouts.

    Vista/Windows 7-style DPI changes should still be fine-- Microsoft did a really good job on that.

    (That said, of course you still should test it both ways. You can turn on XP-style DPI in Vista/Windows 7.)

    Also, I can't speak for OS X.



  • @blakeyrat said:

    Vista/Windows 7-style DPI changes should still be fine-- Microsoft did a really good job on that.

    Really? How does it work?



  • @derula said:

    Really? How does it work?
    Like this (as long at the application doesn't have a dpiAware manifest - if it has it, it does the exact same thing as XP).



  • @derula said:

    @blakeyrat said:
    Vista/Windows 7-style DPI changes should still be fine-- Microsoft did a really good job on that.

    Really? How does it work?

     

    Instead of just scaling fonts, it scales everything-- widgets, bitmaps, etc. Then it lies to the application about x/y coordinates.

    For example, if I had the DPI set to 200%, Windows will draw everything in the app's window at 200% normal size. Then when I click at 400,200 on the screen, Windows tells the app that I clicked at 200,100. There's also a manifest option to tell Windows "hey, I know all about your DPI changing, don't bother doing that for me, I do it correctly-- I swear!!" to override this behavior.

    Frankly, and realistically, that's the best way of doing it, since Microsoft hasn't made much progress in getting third-parties to make resolution-independent apps. This way, almost all apps work fine, even legacy ones with no chance of being fixed.

    Of course, since this Java app is using non-standard widgets, Windows will have to resort to just scaling the bitmap and it'll look like ass. But... it's not magic.



  • @pbean said:

    I really find the Java Layout Manager to be very unintuitive.
    Hey, be fair to Java.  They have a bunch of different layout managers.  And some of them are quite intuitive... they just happen to also be so underpowered that they're useless for any real purposes.


Log in to reply