Re: Whither LVM replacement?
Jonathan de Boyne Pollard
>>
> Phase 1 (the install-time GUI) is pretty mature now.
>
> Phase 2, a full-fledged LVMGUI replacement, is on the back burner
> until either somebody decides to implement it, or (more likely) I've
> learned enough about programming in PM and GPI to be able to write it
> myself.
>
The screen shots were mockups?
> My TODO list is very long, however...
>
You should see mine. I might send the Progress-o-Matic URL to you, in
fact, just so that you can. (-:
Alex Taylor
<J.deBoynePoll...@NTLWorld.COM> wrote:
> >> Whatever happened to your LVM replacement, by the way?
> >
> > Phase 2, a full-fledged LVMGUI replacement, is on the back burner
> > until either somebody decides to implement it, or (more likely) I've
> > learned enough about programming in PM and GPI to be able to write it
> > myself.
>
> The screen shots were mockups?
If you mean the ones here:
http://users.socis.ca/~ataylo00/os2/toolkits/lvm/redesign/
Then yes, they were drawn in MS Paintbrush.
I did later create a simple prototype application that could actually
read the current disks and display something like the GUI depicted above
with real data from the system. Some screenshots of that one might also
have gotten loose. I wrote it using Dynamic Windows, which at the time
allowed me to draw the graphics without knowing GPI. However, I ended
up shelving it after deciding that DW wasn't yet sophisticated enough to
do everything I needed. (And since DW seems to have been abandoned by
its author now...)
--
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00
Please take off hat when replying.
Jonathan de Boyne Pollard
>>
> If you mean the ones here:
> http://users.socis.ca/~ataylo00/os2/toolkits/lvm/redesign/
> Then yes, they were drawn in MS Paintbrush.
>
That's a shame. They looked good.
> I did later create a simple prototype application that could actually
> read the current disks and display something like the GUI depicted
> above with real data from the system.
>
It's interesting to hear of a case where the obstacle is the GUI
programming. Usually it's the application logic proper, the "model"
part of the Model-View-Controller triple. (-:
You should be able to work something up with mostly ordinary controls,
no GPI needed. The stuff at the top left looks doable with just a
standard container control. Similarly, the stuff at the top right is
just a collection of statics and a listbox (or another container). It's
really only the graphical bar representations of disc space where you'd
have to become involved with GPI. And it's not that onerous. It's not
as if you'd be drawing complex polygons or curves. A subclassed static
control and some rectangle drawing and text drawing should be enough.
Ironically, the GUI version of the utility would be a lot easier to work
up, in the above manner, than the TUI version that you mocked up. A TUI
program would need a whole extra library to provide the basic windows,
controls, message processing and suchlike, the stuff that Presentation
Manager does for a GUI application without the application needing to.
(I speak from experience. I wrote one. If you've used the MORE command
from my 32-bit CMD, you've seen it in action.)
Alex Taylor
<J.deBoynePoll...@NTLWorld.COM> wrote:
> It's interesting to hear of a case where the obstacle is the GUI
> programming. Usually it's the application logic proper, the "model"
> part of the Model-View-Controller triple. (-:
The underlying logic isn't really that complex. I basically just take
the user's input, translate that into the necessary parameters, and
pass those off to the LVM APIs. Of course, there's a BIT more I end
up needing to do in practice, but the program probably doesn't even
need to be multithreaded.
> You should be able to work something up with mostly ordinary controls,
> no GPI needed. The stuff at the top left looks doable with just a
> standard container control. Similarly, the stuff at the top right is
> just a collection of statics and a listbox (or another container). It's
> really only the graphical bar representations of disc space where you'd
> have to become involved with GPI. And it's not that onerous. It's not
> as if you'd be drawing complex polygons or curves. A subclassed static
> control and some rectangle drawing and text drawing should be enough.
Yeah, that's pretty much the approach I took in my DW-based prototype.
In fact, the main wall I ran up against, and the one that's still
holding me back now, is that I have absolutely no clue how to make a
graphical control like that scrollable. The PM toolkit documentation
is quite useless on the subject, and the few OS/2 programming tutorials
I've read barely even touch on effective use of scrollbars.
I assume I probably need to draw the whole graphic into some kind of
offscreen canvas, then calculate the visible area whenever the scrollbar
moves, and display only that... somehow. Unless there's some easier
way, but I have no clue what that would be.
By the way, if you want to play with my old prototype, here it is:
http://users.socis.ca/~ataylo00/os2/lvm/redesign/lvmpm_proto.zip
All it does is show static information about the current system state.
The graphic is very crude (and selecting one partition on the graph
fails to deselect the previous one, stupidly enough), and not
scrollable (as mentioned)... but as a proof-of-concept I was fairly
pleased with it at the time.
As I said, though, I decided to throw it out and start over. DW just
has too many limitations (no modal dialogs, for instance), and I know
enough about PM these days that it probably wouldn't be significantly
harder to just use that.
> Ironically, the GUI version of the utility would be a lot easier to work
> up, in the above manner, than the TUI version that you mocked up. A TUI
> program would need a whole extra library to provide the basic windows,
> controls, message processing and suchlike, the stuff that Presentation
> Manager does for a GUI application without the application needing to.
> (I speak from experience. I wrote one. If you've used the MORE command
> from my 32-bit CMD, you've seen it in action.)
Yeah, I've come to appreciate that. I made those designs before I
really knew anything about OS/2 programming...
Jonathan de Boyne Pollard
> holding me back now, is that I have absolutely no clue how to make a
> graphical control like that scrollable.
>
listboxes and containers, making the things scrollable is relatively
trivial. (-:
> I assume I probably need to draw the whole graphic into some kind of
> offscreen canvas, then calculate the visible area whenever the
> scrollbar moves, and display only that... somehow. Unless there's some
> easier way, but I have no clue what that would be.
>
The usual way is to have a scrollbar as an owned child control, to
respond to scroll notifications (WM_SCROLL/WM_HSCROLL) received by the
owner from that child by setting the scroll position, and to redraw as
appropriate from that saved position whenever a WM_PAINT comes along.
No double-buffering. No off-screen canvases. Just a variable that says
"The top position is currently N lines down from the real top.", logic
to change that number whenever a scroll bar says there's been a scroll
event, and logic in the painting code to draw starting at that offset,
accordingly. This is a slight simplification, but it's the basics of
the mechanism.
The magic is in WinScrollWindow(), which arranges for the WM_PAINT to
come along as necessary. See this EDM/2 article for some more information:
http://www.edm2.com./os2api/Tutorials/ScrollBars.html
> By the way, if you want to play with my old prototype, here it is:
> http://users.socis.ca/~ataylo00/os2/lvm/redesign/lvmpm_proto.zip
>
Would that I could! Unfortunately, I am unable to use Presentation
Manager on my development machine. For reasons that elude me, it simply
*will not* go into graphics mode when Workplace Shell tries to start
up. This is with the VGA base video handlers and the IBMVGA32 display
drivers in OS2.INI.
Alex Taylor
<J.deBoynePoll...@NTLWorld.COM> wrote:
> > In fact, the main wall I ran up against, and the one that's still
> > holding me back now, is that I have absolutely no clue how to make a
> > graphical control like that scrollable.
>
> Which control are we talking about? We were discussing several. For
> listboxes and containers, making the things scrollable is relatively
> trivial. (-:
Yeah, I mean the graph panel.
> > I assume I probably need to draw the whole graphic into some kind of
> > offscreen canvas, then calculate the visible area whenever the
> > scrollbar moves, and display only that... somehow. Unless there's some
> > easier way, but I have no clue what that would be.
> >
> The usual way is to have a scrollbar as an owned child control, to
> respond to scroll notifications (WM_SCROLL/WM_HSCROLL) received by the
> owner from that child by setting the scroll position, and to redraw as
> appropriate from that saved position whenever a WM_PAINT comes along.
> No double-buffering. No off-screen canvases. Just a variable that says
> "The top position is currently N lines down from the real top.", logic
> to change that number whenever a scroll bar says there's been a scroll
> event, and logic in the painting code to draw starting at that offset,
> accordingly. This is a slight simplification, but it's the basics of
> the mechanism.
>
> The magic is in WinScrollWindow(), which arranges for the WM_PAINT to
> come along as necessary.
OK, does that imply that I simply create the control as one graphic,
draw the whole thing w/GPI, and then WM_PAINT sets the clipping region
to only show what's "visible"? Actually, that would kind of make
sense... :)
Thanks!
> > By the way, if you want to play with my old prototype, here it is:
> > http://users.socis.ca/~ataylo00/os2/lvm/redesign/lvmpm_proto.zip
> >
> Would that I could! Unfortunately, I am unable to use Presentation
> Manager on my development machine. For reasons that elude me, it simply
> *will not* go into graphics mode when Workplace Shell tries to start
> up. This is with the VGA base video handlers and the IBMVGA32 display
> drivers in OS2.INI.
The zipfile only contains the binaries; I didn't bother zipping up the
source code, which isn't particularly useful if you don't have a Dynamic
Windows dev environment set up.
Jonathan de Boyne Pollard
>
> draw the whole thing w/GPI, and then WM_PAINT sets the clipping region
> to only show what's "visible"? Actually, that would kind of make
> sense... :)
>
When you get a WM_PAINT you're told the window-relative co-ordinates of
the part that needs painting. Scrolling support simply entails a
conversion from window-relative to underlying-view-relative. You're
told, for example, that lines 0..J of the window need repainting. You
simply add the scroll offset and paint lines 0+n..J+n as lines 0..J.
As for drawing the whole thing with GPI as a single control, you could
do that. But there are other approaches:
APPROACH ONE: Use an ownerdraw listbox. It's a scrollable list of
rows, each row denoting a physical drive, right? That can be done with
an ownerdraw listbox. You're told which entry in the listbox needs
painting, by a message sent from the listbox to its owner, and you draw
the appropriate element. The listbox will handle the scrolling part.
You just need to do the ownerdraw stuff.
APPROACH TWO: Use a container, again with the owner drawing the
non-text portions. This is probably overkill, but it's another possibility.
APPROACH THREE: Use grandchild windows. Use a subclassed static or
something as a blank "pane", with a scrollbar child, and place
individual statics for the rectangles, the drive pictures, and the text
on top of that, as grandchildren of your original client area. The
children are positioned relative to their parent, and clipped within the
parent "pane" (assuming you've set the appropriate window style flags)
so scrolling them around is a simple exercise in WinSetWindowPos(). The
pane receives scroll event notifications from its scrollbar child, in
response to which you simply shift its children around. The only
messing about with GPI that you need to do is for the rectangular drive
space displays themselves, which are statics that you subclass and draw
coloured boxes and drive letters in. The other text and pictures are
ordinary controls that you simply use as-is.
The third approach is the most in the "spirit of Presentation Manager".
Building things up from a collection of child windows is done all over
the place, from comboboxes to standard frame windows. (There's a
WINSIGHT tool in my OS/2 Command Line Utilities that displays the
hierarchy. I have a vague recollection that IBM VisualAge C/C++ came
with a similar tool that displayed window relationships "three
dimensionally".)
>> Would that I could! Unfortunately, I am unable to use Presentation
>> Manager on my development machine. For reasons that elude me, it
>> simply *will not* go into graphics mode when Workplace Shell tries to
>> start up. This is with the VGA base video handlers and the IBMVGA32
>> display drivers in OS2.INI.
>>
> The zipfile only contains the binaries; I didn't bother zipping up the
> source code, which isn't particularly useful if you don't have a
> Dynamic Windows dev environment set up.
>
The same still applies.
Andy
<mai...@reply.to.address> wrote:
(And since DW seems to have been abandoned by
> its author now...)
>
Primarily being updated for REXX/DW (by the Regina REXX author) and no
longer by the initial creator of the program.
Andy
--
Alex Taylor
<J.deBoynePoll...@NTLWorld.COM> wrote:
> When you get a WM_PAINT you're told the window-relative co-ordinates of
> the part that needs painting. Scrolling support simply entails a
> conversion from window-relative to underlying-view-relative. You're
> told, for example, that lines 0..J of the window need repainting. You
> simply add the scroll offset and paint lines 0+n..J+n as lines 0..J.
Well, I was intrigued enough by this discussion to try a fairly simple
implementation: adding scrolling capability to my Unicode text control
in DBCSMAP (i.e. the clipboard buffer preview panel).
After some considerable trial and error, I did get it working much as
you said. I didn't end up using WinScrollWindow, however, because I
just couldn't get it to work (the available documentation is pretty
vague on how it actually functions.) OTOH, just calculating the drawing
offsets myself seems to work fairly well, and wasn't that complicated.
> APPROACH THREE: Use grandchild windows. Use a subclassed static or
> something as a blank "pane", with a scrollbar child, and place
> individual statics for the rectangles, the drive pictures, and the text
> on top of that, as grandchildren of your original client area. The
> children are positioned relative to their parent, and clipped within the
> parent "pane" (assuming you've set the appropriate window style flags)
> so scrolling them around is a simple exercise in WinSetWindowPos(). The
> pane receives scroll event notifications from its scrollbar child, in
> response to which you simply shift its children around. The only
> messing about with GPI that you need to do is for the rectangular drive
> space displays themselves, which are statics that you subclass and draw
> coloured boxes and drive letters in. The other text and pictures are
> ordinary controls that you simply use as-is.
I will probably adopt this approach. Thanks for the advice!
Andy
Starting three days after I posted the above... The original author
has made a whole slew of updates.
http://svn.netlabs.org/dwindows/timeline
Andy
--
Brian Smith
> I did later create a simple prototype application that could actually
> read the current disks and display something like the GUI depicted above
> with real data from the system. Some screenshots of that one might also
> have gotten loose. I wrote it using Dynamic Windows, which at the time
> allowed me to draw the graphics without knowing GPI. However, I ended
> up shelving it after deciding that DW wasn't yet sophisticated enough to
> do everything I needed. (And since DW seems to have been abandoned by
> its author now...)
It has not been abandoned... I was busy with some other projects so
hadn't had a lot of time to dedicate to it, but Mark has been doing a
good job of maintaining it. I've spent a bunch of time on it
lately... most of the time spent porting to the Mac using Cocoa and
rewriting the GTK version for GTK3. However new features have been
added with code and suggestions from Mark on all platforms. (There are
a couple features still missing from the OS/2 version... like the
embeddable browser and calendar controls). But anything that OS/2 has
support for I will try to keep up-to-date.
What isn't it sophisticated enough to do? I'd be happy to add support
for anything I can.
( I don't use my gmail account often... so it is better to contact me
via br...@dbsoft.org )
Thanks,
Brian
Alex Taylor
> It has not been abandoned... I was busy with some other projects so
> hadn't had a lot of time to dedicate to it, but Mark has been doing a
> good job of maintaining it. I've spent a bunch of time on it
> lately... most of the time spent porting to the Mac using Cocoa and
> rewriting the GTK version for GTK3. However new features have been
> added with code and suggestions from Mark on all platforms. (There are
> a couple features still missing from the OS/2 version... like the
> embeddable browser and calendar controls). But anything that OS/2 has
> support for I will try to keep up-to-date.
OK, that's good to know.
> What isn't it sophisticated enough to do? I'd be happy to add support
> for anything I can.
Off the top of my head, the main hurdles I ran into at the time were
lack of support for app-modal dialogs, and that I couldn't find any
way to hook up a scrollbar to a custom canvas (although that one may
have been a documentation issue).
Brian Smith
> Off the top of my head, the main hurdles I ran into at the time were
> lack of support for app-modal dialogs, and that I couldn't find any
> way to hook up a scrollbar to a custom canvas (although that one may
> have been a documentation issue).
That is true I didn't add support for modal dialogs, which is kind of
a personal philosophy. I have rarely seen the need for them in
applications, they seem to be abused by programmers. There may be a
way to do it though since Dynamic Windows is a native API... so even
if our API doesn't support things directly... you can pass in native
flags and use native functions (as long as you either use #ifdef
__OS2___ or don't care about being cross platform).
Can you give me an example of when a modal dialog would be necessary?
The second part is probably documentation... connect
DW_SIGNAL_VALUE_CHANGED to a scrollbar created with dw_scrollbar_new()
will fire your callback whenever the scrollbar is moved... you can
then adjust your canvas... This is demonstrated in the test program
using the render area widget. (You have to choose a text file with
the "Browse" button on the first tab... then switch to the Render tab
to see the demonstration).
Also, I plan to work on getting updated documentation up on my web
site once I finish the work I am doing now.... so hopefully that will
help.
Brian
Alex Taylor
> > Off the top of my head, the main hurdles I ran into at the time were
> > lack of support for app-modal dialogs, and that I couldn't find any
> > way to hook up a scrollbar to a custom canvas (although that one may
> > have been a documentation issue).
>
> That is true I didn't add support for modal dialogs, which is kind of
> a personal philosophy. I have rarely seen the need for them in
> applications, they seem to be abused by programmers. There may be a
> way to do it though since Dynamic Windows is a native API... so even
> if our API doesn't support things directly... you can pass in native
> flags and use native functions (as long as you either use #ifdef
> __OS2___ or don't care about being cross platform).
>
> Can you give me an example of when a modal dialog would be necessary?
They are generally useful for prompt dialogs or other things where it's
natural to suspend interaction with the primary window. And there are
many cases where there's no particular need to have a non-modal dialog
but it would be extra work to properly manage one (e.g. working out
how to handle messages when a dialog is open).
> The second part is probably documentation... connect
> DW_SIGNAL_VALUE_CHANGED to a scrollbar created with dw_scrollbar_new()
> will fire your callback whenever the scrollbar is moved... you can
> then adjust your canvas... This is demonstrated in the test program
> using the render area widget. (You have to choose a text file with
> the "Browse" button on the first tab... then switch to the Render tab
> to see the demonstration).
>
> Also, I plan to work on getting updated documentation up on my web
> site once I finish the work I am doing now.... so hopefully that will
> help.
OK, useful to know. Thanks!