Liquid layouts

Your posting mixes a few the concepts: "liquid layout" , "resizable, screen-scaling", "HTML", and "window resizing" which suggests desktop.

The current focus of the GUI (as introduced at Exchange 2006 and PTWs) is Windows .NET Desktop GUI and WPF. From that perspective it will support automatic resizing and screen-scaling of containers and controls; as long as the .NET (or third party) controls have support for it.

OK, I guess screen scaling is part of Vista i.e. 2x, 4x etc. the entire window, right ? and theres a screen scaling helper slash utility available in the AppBuilder for a long time.

Resizable controls or widgets, or the auto-resize attribute by itself isn't new and IMVHO isn't completely what we're after.

The real thing is liquid layouts, we want to define resizeable layout, similarly to functionality built into Dynamics, but not exactly.

The first thing every customer expects in every screen is that dragging the windows corner or to drag some part of the screens border and have the layout automagically rearrange itself.

It hasn't been made clear if that capability will be available in the new GUI.

If it is not, I think, it's very important to discuss the very basic features needed in the new GUI so the community or a company can pick up the challenge and offer a solution.

Maybe as layout managers, maybe a more standards based XML and CSS similar to XUL etc.

If the containers and controls (.NET or third party's) have support for it, then it should just work.

Can you go about saying (in ABL) this frame (or the new GUI equivalent) width will be 70% of the screen, and this fill-in (or equivalent) will be 10px to the right of his container, or something like that.

And when the window is resized it will automatically rearrange according to these rules, please say yes ???

I know that .NET and 3rd party controls will have this capability, it's expected from any up-to-date control. I figure from your answer that capability will not be part of ABL's new GUI.

That was the intended question from a previous thread I posted, the answer then was yes resizable controls will be possible. You could also see the same question in the comments section for the new GUI presentation page. Of course we're not asking if the width for a widget can be changed.

Salvador, please click on pracitcally any program, build with practically any language, in the last ten years installed on your PC. Drag the corner of the window, or drag a pane's border (as can be done in Eclipse) and the layout rearranges and adjusts itself.

Customers, developers, companies, all of them are going to be expecting that capability from a modern up-to-date interface, especially after the huge build up of the new GUI.

They're going to try to put something together themselves, and lacking a good solution, will lead to bigger more cumbersome programs, or failed costly attempts. It's going to lead to unhappy, frustrated customers. I think it could potentially lead to another, following, problematic experience like ADM and Dynamics.

I think, it is important to discuss a few basic features to be included in the new GUI, so the community or companies can offer patterns, code, open-source or commercial utilities. And eventually be a goal for the new GUI.

I think, if this issues are addressed now there's plenty of time for the community or a company to act.

With the new GUI you will work with ABL only. No need to use C#, VB, etc. or development tools like Visual Studio. All this means that, for example, UI control properties can be set/get with ABL, their methods can be invoked from the ABL, and ABL can be used to do event handling of the UI events.

So the short answer to your question is yes.

Salvador

Hello Salvador,

Thank you for answering my question, please read the entire post.

Again, I fully realize that there will be native support for the new GUI, UI controls properties can be set/get from ABL and the same goes for event handling.

But it is not different from the current handling of UI controls, and I think that by itself is too basic of a capability from what's expected.

My question is, can you declare the layout, positioning, sizes etc. in ABL and when the layout, for example, the entire window resizes the layout rearranges and adjusts automatically without having to code the behavior for rearranging the layout programmitcally, which is alot more difficult then it looks for more reallistic, complex layouts.

For example, can I say x section is 40% of the window's width and when the window resize that x section automatically readjusts to the current window size.

Progress already realized people needed that capability in the case of Dynamic and built it into framework, it is certainly a very common, and expected behavior.

Why do I think it is so important ? because IMHO it is a part of every up-to-date, competitive user interface.

And secondly from my experience it is something alot of your users (like me) for a long time have been struggling to write.

If the question is clear enough, then I can go on to discuss what are the basic capabilities that will make writing a solution much more simple and practical.

Alon,

The end-user (by dragging on the window corner) or the developer (programmatically) will be able to do dynamic resizing with scaling.

Regards,

Salvador

Scaling as in changing the dots-per-inch of an application window ?

Yes.

Thank you

It does have a different look then liquid layouts like solution.

I mean dots-per-inch probably works very well for graphics, like, stretching or shrinking an image but don't you think liquid layout are still most suitable for application screens ?

Take for example, Eclipse, where parts of the screen can be resized separately, like, the editor. How would it look if instead of resizing the editor control, repositioning a few buttons and tags and such, the dots-per-inch would be changed just for that part of the screen.

Or another example, is one application with several open windows, with different dots-per-inch settings ? it's different, might be good or it might not.

If I would have to say only a single feature that would make writing liquid layouts far more practical is if there was a refreshable atribute for windows or frames, that offers samilar functionality as in the browse widget.

Today this functionality can be achieved using WIN32 API's, I wouldn't know where to start with Vista but I'm guessing that and much more can be done in Vista.

This feature alone could open many possibilities that may not have been prepared for and customers could be expecting, especially, after the very anticipated new GUI that some people expect to fix everything For example, we the community could start an open-source project.

IMHO it's certainly something to consider very seriously.

Well, I've alread taken enough of your time, thanks for everything.

I'm sure Salvador will clarify more knowledgeably than I can, but I have the idea that you and he are not talking about the same thing.

Have you ever seen an application in which part of the screen was at a different DPI than another part? I don't think that is technically feasible since the DPI is based on the setting in the graphics card, not what an individual window, much less frame within a window sets.

Not only do I not think it is possible, but I don't think it would be desirable.

The message I am getting from Salvador is that this new UI will use the same components that you would use no matter what "host" language you were working in and that these components should be able to do all of the things that they can do in any language environment, but from the control of the ABL. I.e., if you can do it with .NET, you can do it with .NET within ABL. That simple. Right?

Correct. Whatever is (will be) possible with Microsoft .NET shall be possible with the new OpenEdge GUI. The OpenEdge runtime will host a Microsoft's CLR. To the developer and the end-user it will be transparent. The developer will use ABL for everything (bind data in TT, PDS, buffers... to UI controls, get/set properties of UI controls, invoke UI control methods, write event handlers for the UI events subcribed to, etc.). The end-user experience will be as he/she use any application using .NET UI.

The functionality described by Alon is provided by .NET, UI containers, UI controls, WPF.... Again, OpenEdge shall be able to use any of this.

PS. I'm using conditional "shall" because, well, there are dependencies on what Microsoft may or may not decide to keep or do, and because the OpenEdge new GUI product does not exist commercially yet; we are working on it.

Have you ever seen an application in which part of the screen was at a different DPI

than another part? I don't think that is technically feasible since the DPI is based on

>the setting in the graphics card, not what an individual window, much less frame within

a window sets.

>

Thomas, Did I say that ?

I asked a simple one line question to clarify one of the previous answers.

Scaling as in changing the dots-per-inch of an application window ?

And the answer was a clear Yes.

Where I remarked that it maybe a good solution for graphics but not for application screens.

Not only do I not think it is possible, but I don't think it would be desirable.

That's exactly what I said.

From what I remember watching a couple webcasts on Vista, DPI and resolution are not the same, changing the DPI for individual application windows and much more is possible.

The answer before that was it should just work.

Which I had a problem excepting because inorder to rearrange the layout I would first need to define how I would like the layout to be rearranged if it was resized.

I'm sorry for not excepting don't worry, it will do everything. There's a very big different from having all the controls .NET has, and doing everthing a .NET application can, UI wise.

If you ask me a question and I knew the answer I would give you a clear, single answer and be specific on how it can be achieved.

This question seems to be causing too much trouble so I'll drop it.

Did I say that ?

Well, you said:

Take for example, Eclipse, where parts of the screen can be resized separately, like, the editor. How would it look if instead of resizing the editor control, repositioning a few buttons and tags and such, the dots-per-inch would be changed just for that part of the screen.

Or another example, is one application with several open windows, with different dots-per-inch settings ? it's different, might be good or it might not.

That sure sounds like an application in which part of the screen was at a different DPI than another part to me.

on Vista, DPI and resolution are not the same thing.

Are you talking about font scaling? I find it hard to imagine the actual, physical dots per inch of the screen being non-uniform. Moreover, on the ever more popular LCD displays, one wants to run at the "natural" resolution of the screen or one gets a degraded image. But, I can see it is possible to apply different font scalings in different parts of the screen, even within a single application. However, I'm not sure that it buys one anything exciting beyond what one can accomplish by simply using different sized fonts.

Not to mention, of course, that there are lots of applications which handle non-default font scaling very poorly. I know, since I run my screen at 125% scaling because of the high resolution and some things are ugly.

There is no such thing as bad, dumb or troublesome questions. Keep them coming!

During the thread I kept myself from asking you information about actual business use case(s) for the features/functionaliites you were inquiring about. When you have a chance I'd welcome them very much.

Salvador

I think the use case is really quite simple. There is a huge range of screen resolutions in use out there. Design for the minimum, even if one is able to mandate a company minimum which is not as bad as a global minimum, and one ends up with a tiny unreadable window on a large high resolution monitor. Design for the maximum and smaller monitors can't use it. If one can resize to taste, then one can accommodate difference screen sizes, resolution settings, and how recently one has gotten new glasses.

There is no such thing as bad, dumb or troublesome questions. Keep them coming!

Thanks, getting a hang on the language is hard enough by itself

I really don't know a whole lot and haven't had time to look into Vista and WPF yet, and about what's coming in the new GUI.

Here's an example I just saw this week on PEG posted by Arthur Fink -

Having laid out an Appbuilder screen at 1024 x 768 (9.1E), is there a

utility that will scale that screen to an 800 x 600 display?

There were one or two suggestions but none of them were really a solution, finally the screens had to be painstakingly manually rescaled.

I played around with liquid layouts in v8 or v9, if I'll have time this week I'll try putting together a code sample to better illustrate what I mean.