 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2005Layout Managers
So I'm reading through the Teach Yourself Java 2 In 21 Days, and it says that defining dialog items in terms of pixels and locations is highly deprecated in favor of layout managers. But . . . then dialog dimensions, graphics etc. everything else is handled in pixels. I was wondering what these problems that are going to arise are. I will probably end up using layout managers anyway, it is convenient how they work with resized dialogs. I would like to find a tool which will assist me in making dialogs though. I had netbeans, and when I try to make even a simple project I get this huge multidirectory . . .thing. I would like an app that would help me make my layout and then I could cut and paste it into my application. If one does not exist, I imagine I could easily write one. After all, it's not the variables I'm not understanding, it is how to get them working well together that I have a problem with :) -- LTP > <snip> If you're looking for a tool to make nice looking GUIs, netbeans 5.0 (with the matisse layout manager) is the best way to go. However, if what you really want to do is use the GUI to learn how to use the layouts, I'm sure that others would work. What I've done is used netbeans to play around with how stuff gets laid out with certain layout managers, and then translate that knowledge to writing the code manually. There aren't really any IDEs that assist in visual development that make it easy for you to understand the generated code or hand-edit it. I would recommend downloading the new netbeans beta. It's quite sexy.  SignatureOf making better designs there is no end, and much refactoring wearies the body. Benji coughed up: >> <snip> > [quoted text clipped - 4 lines] > netbeans to play around with how stuff gets laid out with certain layout > managers, and then translate that knowledge to writing the code manually. My suggestion to the OP is nearly opposite: Force yourself into writing and designing the GUI manually, in order to learn and understand the layout managers. Once you've accomplished that, *then* you are qualified to handle the crufty looking code that a GUI generator will make. > There aren't really any IDEs that assist in visual development that make > it easy for you to understand the generated code or hand-edit it. > > I would recommend downloading the new netbeans beta. It's quite sexy. Is there anything about it that stands apart from eclipse ($0) or Intelij IDEA ($mondo) ? SignatureIt's time for everyone to just step back, take a deep breath, relax, and stop throwing hissy fits over crossposting. > Benji coughed up: >>> <snip> [quoted text clipped - 10 lines] > layout managers. Once you've accomplished that, *then* you are qualified > to handle the crufty looking code that a GUI generator will make. I suppose this is kinda where I am coming from. But it is the latency between writing, compiling, running, viewing and then re-editing that bothers me. I believe that if I write, from scratch a tool which allows me to use my rudimentary knowledge of Java GUIs to design them the way that I like, I will learn it as well or better than if I had done it "the old fashioned way". What I had an issue with was having no idea what NetBeans was doing. -LTP :) Luc The Perverse coughed up: >> Benji coughed up: >>>> <snip> [quoted text clipped - 23 lines] > > What I had an issue with was having no idea what NetBeans was doing. This logic bothers me a little. You may have to trust me on this one. Writing a GUI generation tool is fine in its own right, but in terms of learning the GUI? By the time you've understood the GUI to build a tool, you've understood well the GUI. It seems like the order of things is reversed. I would suggest building /any other app/ in order to learn the GUI. > Luc The Perverse coughed up: >>> Benji coughed up: [quoted text clipped - 33 lines] > > I would suggest building /any other app/ in order to learn the GUI. Back in high school I learned chemistry best by writing calculator apps to do my homework for me. Granted it would take 4 times as long to write the app as to just do it, but by the time I was done I had concept mastery. There is nothing about GUI generation which I don't understand in theory, or could not understand through simple reading. It is the usage and application that I have an issue with. If there is something which I have veritable difficulty understanding, then I will require more or less concept mastery to implement enough to make a dynamic adjustable GUI editor for that control, something not required in the world of cut and paste for programming for simple one time usage :) So, if the only thing left to learn is how to tweak the corresponding numbers to make the dialog "look" right, then a tool which handles it for me transparently without the middle compilation step, then I would find this tool quite useful. You said yourself, "By the time you've understood the GUI to build a tool, you've understood well the GUI." I agree ;) And learning the GUI was all I ever wanted to accomplish! Perhaps after I have played around with making even half a dozen GUIs I will find it generally intuitive, and no longer need the tool, I can write the code once and have it work great; but I do not believe that this would invalidate building the application as a learning tool. Sorry - I guess we're just going to have to disagree on this one :) -- LTP :) Luc The Perverse coughed up: >> Luc The Perverse coughed up: >>>> Benji coughed up: [quoted text clipped - 33 lines] >> >> I would suggest building /any other app/ in order to learn the GUI. ...[rip]... > There is nothing about GUI generation which I don't understand in theory, > or > could not understand through simple reading. It is the usage and > application that I have an issue with. You're still way off the mark. You learn how to build houses by building houses, not by creating the tools to build the house. You will need to understand the usage and application of GUI's *BEFORE* you create an editor for them. True, you could attempt such a tool, without understanding what direction you're going in, but the part of it that you teach you GUI mastery would be the part of the application /itself/ that requires the GUI, not the GUI generation part. The construction of this "GUI creator's GUI" would be hampered by needs overall of your application (what a GUI requires), which it appears you know almost nothing about. In other words, you don't know what you don't know here. For example, GUI's in java are not thread-safe, and everything must be altered and/or otherwise mucked with in a single special thread. Further, GUI's report back information using special call-backs called "listeners", which are special implemented interfaces. Still further, GUI's require an understanding of two /simultaneous/ hierarchies: inheritance and container. And even further than that, GUI's respond to a cascading set of events that flow between container and component all the way across the container hierarchy. You would gain an understanding of all these by creating, say, a newsreader. But to attempt a GUI generation tool would only slow you down. ...[rip]... Signature"Realtor" and "realty" are pronounced "reel'-tor" and "reel'-tee", *not* "reel'-a-tor" and "reel'-i-tee" !!!! If you pronounce them with the extra syllable, you will sound like a complete idiot. > Luc The Perverse coughed up: >>> Luc The Perverse coughed up: [quoted text clipped - 69 lines] > You would gain an understanding of all these by creating, say, a > newsreader. But to attempt a GUI generation tool would only slow you down. Aha! I have identified the problem as a miscommunication. Your definition of a GUI generation tool exceeds, by at least an order of magnitude, that which I had intended, originally, on creating. Of course now, I am embarassed to try to explain my simplistic implementation. -- LTP :) On Thu, 27 Oct 2005 17:58:58 -0600, "Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly quoted someone who said : >You said yourself, "By the time you've understood the GUI to build a tool, >you've understood well the GUI." I agree ;) And learning the GUI was all >I ever wanted to accomplish! What I think the next stage in Java evolution will be something analogous to what CSS did for HTML and L&F did for decoration. Your code will be concerned with deciding which data should be displayed and its relative importance. Styles "Sheets" will intelligently do layouts. Features I would expect: Ability to format standard demographic classes, adjusting for country, including names, phone numbers. email addresses , web addresses , zips, countries ,streets, etc. The LayoutStyle hides not essential information when the screen real estate is too small. The LayoutStyle handles labelling components when there is room and providing tooltip explantions of editing rules, bounds, and field specifics. The LayoutStyle can set up scrolling displays, scrolling fields, smaller fonts and any other trick do deal with trying to display data in less space than optimal. The layout will be interactive, so that you can get at other information there was not enough room to fully display, with any corresponding application code. A layout might smoothly revalidate for every new set of data, so as not to waste whitespace at the end of fields. In some LayoutStyles the visual experience will be sinuous, as if watching the display on the body of an octopus. Eye-direction monitoring will provide clues to the Layout Style just what on screen you consider important and smoothly enhance or expand that. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Benji coughed up: >> <snip> > [quoted text clipped - 8 lines] > There aren't really any IDEs that assist in visual development that > make it easy for you to understand the generated code or hand-edit it. I've investigated such things in the past, and unless something's changed in the last few years, maintenance of GUI code over many cycles of auto-code generation and tweaking of such code approaches the impossible. It is for this reason that nearly everyplace I've been, manual construction has been favored. > I would recommend downloading the new netbeans beta. It's quite sexy. On Thu, 27 Oct 2005 16:34:50 GMT, "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote, quoted or indirectly quoted someone who said : > It is for >this reason that nearly everyplace I've been, manual construction has been >favored. I used GUI generated code early on my career as a learning tool, just create starting point. The problem was , as soon as I hand customised it even the tiniest bit I could no longer use the gui tools. The code was uncommented, and somewhat weird, not designed for legibility. I later used stompers, -- home brew templates written in Java, that would generate idiomatic code. These are mainly useful for initially writing the code. One advantage of this technique is you can always customise it. Further the boss need never know how you wrote the pages of perfectly consistent code. From his point of view the results are even more maintainable than if you did them by hand. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. On Wed, 26 Oct 2005 20:42:50 -0600, "Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly quoted someone who said : >So I'm reading through the Teach Yourself Java 2 In 21 Days, and it says >that defining dialog items in terms of pixels and locations is highly [quoted text clipped - 16 lines] >easily write one. After all, it's not the variables I'm not understanding, >it is how to get them working well together that I have a problem with :) Java is in for trouble down the road. For now, layout managers let you write code without detailed pixels, but they still calculate everything in pixels. Recent LCDs use a hardware resolution between 86dpi and 147dpi, only a few LCDs use a resolution around 204dpi (Toshiba, IBM). The problem is ordinary Java apps look too small on these high resolution screens, because Java apps are constructed in pixels, not points or inches the way PostScript is. A program that draws an icon 32 pixels high looks huge on a low res screen, but shrinks down to a mite on an ultra highres screen. Quoting from my resolution essay where I propose doing layouts in a new unit, the VU. "VU. Visual Units. This is my personal proposal. One VU is the vertical distance between two lines of type the user can comfortably read. It is the leading of the user's preferred body font. What it corresponds to in cm or pixels depends on many factors including visual acuity, personal preference and screen resolution. My idea is you would design in visual units, and the user would configure the value of a visual unit in pixels using a system wide slider in the control panel. The definition would then by used by the OS and all apps. The user could adjust it an any time, causing a system wide revalidate. The GUI and layouts would still work in pixels at the low level, but for various higher level methods you could specify co-ordinates and sizes in terms of a VU grid, or perhaps in terms of integral MVUs, thousandths of a VU. The notion could be used both for designing screen layouts and printed output easily readable by the user." For more discussion of the issues you are raising see http://mindprod.com/jgloss/layout.html http://mindprod.com/jgloss/resolution.html http://mindprod.com/jgloss/coordinates.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy Green coughed up: ...[rip]... > Quoting from my resolution essay where I propose doing layouts in a > new unit, the VU. [quoted text clipped - 14 lines] > designing screen layouts and printed output easily readable by the > user." It is patently ridiculous that in this day and age we are not specifying nearly everything in resolution independant formalisms. Points, inches, centimeters, lightyears or hydrogen atom width. Display postscript (no and not sun news) was a perfect solution to this: it drove the NeXT machines perfectly. The slider you are talking about might as well be a general purpose scale. Even the thin lines and "individual pixels" of an application (or what the application thinks are thin lines and individual pixels) can be managed far better when drawn appropriately in the first place. Far better than any AA or low end sub sampling or Box resizing. > Roedy Green coughed up: > [quoted text clipped - 31 lines] > far better when drawn appropriately in the first place. Far better than > any AA or low end sub sampling or Box resizing. I imagine as legacy applications start becoming unrunnable, OS (and possibly JVM) options will exist that allow pixels to be multiplied by some factor in an emulation mode, to alleviate the problem :) -- LTP :) On Thu, 27 Oct 2005 17:51:22 -0600, "Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly quoted someone who said : >I imagine as legacy applications start becoming unrunnable, OS (and possibly >JVM) options will exist that allow pixels to be multiplied by some factor in >an emulation mode, to alleviate the problem :) But to properly emulate the Java program, the only scales that would not have artifacts would be powers of two. Java would have to internally work with virtual pixels. It would be even less direct than the DOS character REGEN buffer emulation. Yuchh! Much better to head the problem off at the pass and start writing higher level scaleable code. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On Thu, 27 Oct 2005 17:51:22 -0600, "Luc The Perverse" > <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly [quoted text clipped - 13 lines] > Much better to head the problem off at the pass and start writing > higher level scaleable code. I don't think it is going to happen until the problem is manifest. I still run installer programs who default from a hard coded string (in windows) to c:\program files\ even though I don't have the letter C assigned to a partition. Then they complain about their not being enough room. If the problem is serious enough, video cards will start to be made with virtual smaller resolution emulation modes, which will handle in hardware the overhead of stretching the application. While I agree with you that it should be fixed, Sun will not force something on programmers which will anger so many of them -- LTP :) On Thu, 27 Oct 2005 19:53:53 -0600, "Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly quoted someone who said : >I don't think it is going to happen until the problem is manifest. It is beginning to show up with the high end LCD panels. It shows up when you do printing. Printers vary widely in resolution and of course they are in a different order of magnitude from screens. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy Green coughed up: > On Thu, 27 Oct 2005 17:51:22 -0600, "Luc The Perverse" > <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly [quoted text clipped - 8 lines] > But to properly emulate the Java program, the only scales that would > not have artifacts would be powers of two. No, I think you mean "integer multiples" here. Pixels, for example, could easily be drawn 3:1. But it's still the wrong solution. This is the solution already in place when you change monitor resolutions. Effectively, the output is semi-uniformly scaled (to fit your screen). The problem with this is multi-fold, but Postscript, for example allows a line to be widened to whatever width (in real world units) is asked for. A scaled pixel set as is suggested would only keep the same number of stairs in a stair-cased line, but make the stairs fatter. *And*, the artifacts you speak of would only increase like crazy if they were non-integer multiples in the pixel fattening scheme. That is, an AA line in postscript will draw better than an AA line made from fattening pixels 2.5:1. > Java would have to > internally work with virtual pixels. All apps more or less already do. Images, for example, are objects (virtual pixels) that only get blitted to the screen by other java objects. Such objects would "know" what to do. But again, the wrong solution. ...[rip]... Signature"Realtor" and "realty" are pronounced "reel'-tor" and "reel'-tee", *not* "reel'-a-tor" and "reel'-i-tee" !!!! If you pronounce them with the extra syllable, you will sound like a complete idiot. On Fri, 28 Oct 2005 01:58:18 GMT, "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote, quoted or indirectly quoted someone who said : >No, I think you mean "integer multiples" here. Pixels, for example, could >easily be drawn 3:1. But it's still the wrong solution. Yes. That applies to shrinking too which is even more problematic. Shrinking by 1/3 has the added problem you want the image to be a multiple of 3 wide and tall to start, which is not likely to happen by accident. You can't take a finished bit map and stretch it by 5% and expect something readable, but you can if you did the stretch and rounding to pixels mathematically as you drew and let the layouts do intelligent things to preserve regularity. In PostScript there are operators to do a mathematic transform of a point then get the snap-to equivalent pixel. Then you make that your precise new origin. What bothers me is PostScript was aware of these scaling and resolution problems even before Java 1.0. Yet Java jumped right in totally ignoring them. Maybe they just had too many problems on their plate and felt that by the time the problem became acute would be so psychologically far in the future they figured a later generation would deal with it, or perhaps hardware would do the scaling and rendering and the very notion of bitmaps would become quaint antiquities. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy Green coughed up: > On Fri, 28 Oct 2005 01:58:18 GMT, "Thomas G. Marshall" > <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote, quoted [quoted text clipped - 5 lines] > > Yes. That applies to shrinking too which is even more problematic. ...[rip yada...]... I was part of a postscript clone manufacturer. I am intimate with all details regarding it's developement and design, particularly AA and pixel alignment ramifications. The only thing I can imagine is (believe it or not) that a general purpose PDL such as postscript is beyond the abilities of most to implement. This is true to a large extent---take a look at how many postscript clones that would work and then gack on particular pages. Or not work at all. There were a great many joke interpreters. I haven't checked in a while, but gnu's ghostscript was certainly one of them for many years. Signaturehttp://www.allexperts.com is a nifty way to get an answer to just about /anything/. > It is patently ridiculous that in this day and age we are not specifying > nearly everything in resolution independant formalisms. Points, inches, > centimeters, lightyears or hydrogen atom width. We don't have the display resolution yet. This machine has 125 ppi and that's nowhere near enough to be able to ignore pixel boundaries. I'd guess that the old laser printer "standard" resolution of 300 ppi would be enough, but only just. Admittedly there are /some/ applications where it's OK to ignore pixel quantisation, but they tend to be applications where the visible display is only intended to be an approximation to the underlying "truth" (and tend to have zoom operations too). That isn't the case for positioning the elements of a GUI. But still, I'm looking forward to the day when we stop specifying sizes and positions in integers. -- chris On Fri, 28 Oct 2005 11:53:25 +0100, "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly quoted someone who said : >We don't have the display resolution yet. This machine has 125 ppi and that's >nowhere near enough to be able to ignore pixel boundaries. I'd guess that the >old laser printer "standard" resolution of 300 ppi would be enough, but only >just. Consider font rendering. We programmatically ignore the pixels, but inside pixels are far from ignored. there are rendering hints, snap to grid positioning etc. In PostScript there is snap to pixel grid positioning though you work in 1/72 inch units. It is not like a typesetter where you have such fine resolution you can ignore the pixel error. It will be that smarter layouts deal with it automatically, much the way font rendering deals with making fonts look good at low res now using hints, anti-aliasing, snap to positioning/sizing etc. etc. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy Green coughed up: > On Fri, 28 Oct 2005 11:53:25 +0100, "Chris Uppal" > <chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly [quoted text clipped - 9 lines] > inside pixels are far from ignored. there are rendering hints, snap to > grid positioning etc. The notions of this snapping you refer to /are/ part of the term "hinting". > In PostScript there is snap to pixel grid positioning though you work > in 1/72 inch units. [quoted text clipped - 5 lines] > way font rendering deals with making fonts look good at low res now > using hints, anti-aliasing, snap to positioning/sizing etc. etc. Signaturehttp://www.allexperts.com is a nifty way to get an answer to just about /anything/. Chris Uppal coughed up: >> It is patently ridiculous that in this day and age we are not specifying >> nearly everything in resolution independant formalisms. Points, inches, >> centimeters, lightyears or hydrogen atom width. > > We don't have the display resolution yet. This machine has 125 ppi and > that's nowhere near enough to be able to ignore pixel boundaries. Hinting solves that for fonts. Similar algorithms for lines. I've seen them, ported them, worked deep in the muck with them in the past. It is possible. Here was an interesting experiement: We pushed one hinting algorithm to the extreme: Iteratively drawing the lower case 'e' at lower and lower point sizes. You'd watch it (in fat bits) try and try to keep the center of the e open. Until at the very last second it would give up the ghost. ...[rip]... Signaturehttp://www.allexperts.com is a nifty way to get an answer to just about /anything/. [me:] > > We don't have the display resolution yet. This machine has 125 ppi and > > that's nowhere near enough to be able to ignore pixel boundaries. > > Hinting solves that for fonts. Similar algorithms for lines. I've seen > them, ported them, worked deep in the muck with them in the past. It is > possible. I don't think I'd want to mix the complexity of hinting into GUI construction. Although it would be interesting to try to extend the layout manager concept so that it could act as an "advisor" on pixel-level positioning even though the user/programmer only specified positions and relations in a continuous space. -- chris On Sat, 29 Oct 2005 14:46:08 +0100, "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly quoted someone who said : >I don't think I'd want to mix the complexity of hinting into GUI construction. > >Although it would be interesting to try to extend the layout manager concept so >that it could act as an "advisor" on pixel-level positioning even though the >user/programmer only specified positions and relations in a continuous space. For it to work, pixel fiddling has to be taken out of the app. The layout manager may get feedback from lower layers on how many pixels a N unit margin should be, then the layout would do it in pixels from then on to be consistent. I think the detail would come from extended L&F, and more abstract L&Fs, doing bit fiddling. The layout layer would ask the lower layer to round VU units to pixels for it. The app layer would work in pixel-independent biometric units like the VU. I would like to see an animation of a continuously variable layout that morphs smoothly to adjust to the particular data in it, or your particular subinterest in data in a box to show you more details. With some sort of quasi-biological metaphor -- your retinal computation layer may be more at home. We will need a way soon to waste all the new compute power. :-) SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.