ResourceBrowser and VC comments/suggestions

Andy,

A wise man once wrote:

> We do have plans to improve the Resource Browser in the near future.
> I quite agree; the existing interface borders on the atrocious!

Actually, I wouldn't be that hard on it.  A big part of the problem is that
Dolphin allows all of us to create lots of great stuff, which results in a
long list.  I do somewhat miss the separation that came from
CompositePresenter, both because it made more sense to look for containers
under it, and because it makes for much less scrolling than Presenter.*.
One idea would be to add a separate card with buttons that filter/scroll the
list of resources.  A clever IDE extension might be even better??

The current method for creating toolbars _might_ be worthy of your above
characterization :)  The ability to pull the images from outside is great
and should of course remain, but it would be nice to have the option to edit
and save the bitmaps in the image, ideally on a per-button basis.  Any
"arrayed" bitmap needed by a toolbar could be created on demand from the
individual images.

Another thing I'd like to see (it's been mentioned here before) is a labeled
text presenter, with some way to move the two as a unit, and perhaps
individually (though control over the label's size would probably be
sufficient).  One can acheive it with static and editable controls in a
container, but there must be a better way.

When pasting views in the VC, it might be nice to have an option to paste at
a particular location.  It's easy enough to find the new sub-view in the
view hierarchy and set it's #position, but that step could be skipped in
many situations.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

> In the past we have looked at adding the ability to the deployment wizard
to
> be able to move the bitmaps (the small  ones at least) into the image so
that,
> if nothing else, one doesn't have to distribute a load of bitmap files
along with
> an application because they could all be inside the executable.

That would be cool, I e.g. deliver the 1.4MB resource dll with my 600kb app
just for the little sort-direction arrowheads in the listview :-).

Ciao

...Jochen

"Jochen Riekhof" <[hidden email]> wrote in message
news:[hidden email]...
> > In the past we have looked at adding the ability to the deployment
wizard
> to
> > be able to move the bitmaps (the small  ones at least) into the image so
> that,
> > if nothing else, one doesn't have to distribute a load of bitmap files
> along with
> > an application because they could all be inside the executable.
>
> That would be cool, I e.g. deliver the 1.4MB resource dll with my 600kb
app
> just for the little sort-direction arrowheads in the listview :-).
>

I experienced the same issue, Steve Waring had a great suggestion, you can
find his tip here:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=ak4j0l%241fjkot%241%40ID-65212.news.dfncis.de

Chris

> I experienced the same issue, Steve Waring had a great suggestion, you can

works excellent, thanks a lot!

Ciao

...Jochen

Andy,

> Yes, the basic functionality is okay, it's just that it's very difficult
to
> find anything in there.

Sounds good.


> The current requirement to have bitmaps in files outside of the image is
> rather cumbersome, I agree.

I think we're on the same page.  Just to take another swing at the dead
horse: pulling the images from the outside is a great feature to have, but
it would be nice to have in-image option too.


> In the past we have looked at adding the
> ability to the deployment wizard to be able to move the bitmaps (the small
> ones at least) into the image so that, if nothing else, one doesn't have
to
> distribute a load of bitmap files along with an application because they
> could all be inside the executable.  You might, of course, say why not
> actually load the bitmaps and icons into the true resource section of the
> EXE.

I'm not sure that it makes much difference to me, but it might to users.  It
might be more important for COM DLLs???


> Traditionally the reason for this has been because unless one is
> deploying on a Windows NT derivative (2000, XP) then mucking around with
the
> resource section of an EXE is quite tricky and we haven't wanted to limit
> deployment to these operating systems just yet.

I think that's wise, but it's also reasonable to add deployment options on
nt and up.


> However, as you say, it might be useful to be able to handle bitmaps/icons
> that are stored in the image even at development time.  This would make
> doing things like toolbar buttons and icons (which are small enough to
make
> sense being stored in the image anyway) much easier.

Agreed.  In fact, I've sometimes found myself avoiding toolbars because of
the extra steps.


> We'll bear it in mind,
> thanks (recorded as issue #1338).

Thanks.


> > Another thing I'd like to see (it's been mentioned here before) is a
> labeled
> > text presenter, with some way to move the two as a unit, and perhaps
> > individually (though control over the label's size would probably be
> > sufficient).  One can acheive it with static and editable controls in a
> > container, but there must be a better way.
>
> Now this idea I'm not quite so keen on.  Back in the dim and distant past
> when Blair and I used to work for Intuitive Systems we worked on a 4GL
tool
> called Intuitive Solution.  One of the enhancements that was added to the
> GUI builder of this tool was some way of associating labels with text in
> just the way that you suggest.  However, if I remember correctly, it never
> worked quite right; they were simply too many things to configure (label
> fonts, label height, label alignment, label width, text font, text height,
> text alignment, text width, whether the text was numeric etc).  Perhaps a
> better way of doing it might be to employ some sort of special-purpose
> layout manager to group the existing controls within a container.

That would be at least as good, probably better.  Could FramingLayout do the
job given modified constraints?


>  This
> might also involve doing something like "locking" the contents of
container
> so that once the initial properties of the label and text field have been
> set up they can be locked in a way such that mouse clicks do not drill
down
> into them and container feels more like a single item.

That might be useful in other situations too, as long as it could be turned
on/off as needed.



> > When pasting views in the VC, it might be nice to have an option to
paste
> at
> > a particular location.  It's easy enough to find the new sub-view in the
> > view hierarchy and set it's #position, but that step could be skipped in
> > many situations.
>
> IIRC, when the View Composer was originally being written I think the
> specification called for the pasting to be done at the position of the
last
> mouse click.  However, obviously never got implemented (probably due to
lack
> of an Sunit test to give a failing report). Recorded as issue #1339.

Thanks!  BTW, if you write such a unit test, I'd very much like to see it.
I'm doing some smoke testing of GUI elements, but I wouldn't mind adding
more sophisticated tricks to my toolbox.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Andy Bower wrote:

> [re: labeled text presenter]
> Perhaps a better way of doing it might be to employ some
> sort of special-purpose layout manager to group the existing controls
> within a container.

I've found it worthwhile to put together a FormLayoutManager that lays out
sub-components in two columns with "labels" on the left and "values" on the
right.  Sort of like (view this in a fixed-width font):

    ------------------------------------------------------------
    |                                                          |
    |   A Label               [a text edit box               ] |
    |                                                          |
    |   A Longer Label        [X] "a checkbox"                 |
    |                                                          |
    |   A Text Edit           [a multi-line text edit        ] |
    |                         [that is given vertical        ] |
    |                         [height according to its       ] |
    |                         [#preferredLayout              ] |
    |                         [                              ] |
    |                         [                              ] |
    |                                                          |
    |   The Last Label        [                              ] |
    |                                                          |
    ------------------------------------------------------------

It's a bit rough, and part of an incomplete project, but I can extract the code
for anyone who's interested.  However my real point is that it turns out to be
quite easy to create custom layout managers (if you don't get too ambitious --
YAGNI is your friend here), and that is probably a better approach than
devising ever-more-complicated widgetry.

I expect to be using custom layout managers more in future.  It seems to be an
easy way to get the exact layout and behaviour that *I* want.

    -- chris

Chris,

> It's a bit rough, and part of an incomplete project, but I can extract the
code
> for anyone who's interested.  However my real point is that it turns out
to be
> quite easy to create custom layout managers (if you don't get too
ambitious --
> YAGNI is your friend here), and that is probably a better approach than
> devising ever-more-complicated widgetry.

Sounds interesting.


> I expect to be using custom layout managers more in future.  It seems to
be an
> easy way to get the exact layout and behaviour that *I* want.

My Pane Holders package has at least one, and you're right, it wasn't that
bad :)  To layout manager newbies, I offer encouragement with the caveat
that one should save the image before testing each change.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Folks,

> I experienced the same issue, Steve Waring had a great suggestion, you can
> find his tip here:
>
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=ak4j0l%241fjkot%241%40ID-65212.news.dfncis.de

The wiki page that Steve mentions in the above is now on a different server
at:

http://www.object-arts.co.uk/wiki/html/Dolphin/IconsToGo.htm

Best regards

Andy Bower
Dolphin Support