Re: [cssed-devel] Just one more thing to cssed 0.3.0

[Iago R. <iag...@hi...>]

On Wed, 2004-09-22 at 02:57, Mich=C3=A8le Garoche wrote:
> Le 21 sept. 2004, =C3=A0 20:08, Iago Rubio a =C3=A9crit :
>=20
> > On Tue, 2004-09-21 at 13:02, Mich=C3=A8le Garoche wrote:
> >> Le 21 sept. 2004, =C3=A0 12:42, Iago Rubio a =C3=A9crit :
> > [snip]
> >>> Can it go this way or is inusable ?
> >> Strictly speaking, it is usable, but frankly if you should move the
> >> window each you want to access a field or an icon on the toolbar, and
> >> remove it just thereafter, it'll get on your nerves very quickly :-)
> >
> > It must change it  then, Does it needs to fit in less height it's
> > fitting now ?
> No, it was an answer for what existed before I committed the change to=20
> 50*7 for the terminal, now it's ok.

Great.

> >>> We must write it down in the web site "requires 800x600" :(
> >> Yes, because, of course you can split another time the toolbar, but
> >> then you have very little place for the document, and in particular no
> >> more place for viewing the scan selector panel (it cuts before the end
> >> of the hide the lower panel icon).
> > I will test it in the BSD box, it's attached to a small 14' screen and=20
> > -
> > I think - in 800x600.
> It works perfectly here also.

Ok, here too on BSD and Linux.

> >> Another option, but no for this release, would be to use a tool window
> >> (with access to the lower panel in it and all plugins), instead of
> >> using the toolbar, this way the window remains relatively small, and
> >> the user can place both windows overlapping each other.
> > I must think on it, now I'll write some code for the toolbars.
> >
> > We can also float the toolbars, so the user could attach and dettach
> > them.
> It is not sufficient for 640*480 screens; the width of toolbars is=20
> exceeding the screen width.
> Here's a screenshot, the height is perfect, all plugins are loaded,=20
> what is missing is the two icons for hiding panels and the preferences=20
> icon in first toolbar, then the quicksearch search field and its two=20
> backward/forward search icons in the second toolbar.

Those bits will be rewritten for next release, so we must thake this
problem into account and fix it.

________________________________________________________________________
> >> I wonder if it is not the way to go, since as the number of plugins
> >> will grow we have to face that very problem more and more.
> >
> > We must think on it. ITOH I don't expect too much people will use all
> > plugins, or even a huge number of plugins.
> You cannot account on it. So it must be think as if the user will load=20
> all plugins together.

Yes, all plugins in CVS should load ok. Third party one must work on it
their own ;)

> > I also expect more menu based plugins when I fix menu access, and more
> > non ui plugins as file managers and css dialogs.
> Yes, of course, but anyway, all plugins must follow the principle that=20
> their ui must fit on a 640*480 screen. Or 800*600 screen.

For this release we will leave a 800x600 requirement. Nwxt version
should fix this problem with toolbars.

I can also one drop button to put the panels ones into.=20

> > What's sure is the UI - the main window I mean - is limited in the
> > number of widgets.
> Yes. That's why I suggest to put all plugins in a tool window. I don't=20
> know how you could control afterwards (automatically I mean) if a=20
> plugin fits into a given screen, if there is access to the toolbar.=20
> Other widgets seem to resize gracefully, but this one is simply cut.

There're some functions for that in the API y can compare the width of
the GtkToolbar with the width of the given screen (X screen being used).

The problem is not how but when. In X server platforms, you can use an
application and move it throught more than one screen.=20

I mean a user with two - or three - screens can switch the app from one
to other. One screen can be running with at 640x480 and other at any
other screen resolution supported by the video card.

So if I check the length on startup, it can vary when moving throught
screens so it'll be bogus.=20

What I don't want to do, is to waste resources checking the length of
the screen at any window move/resize.

> >>> Great thanks, will split the find in files plugin commands in two=20
> >>> lines
> >>> and we'll see if the whole fits on 800x600.
> >> OK.
> > Please test the changes in cvs. Patch attached.
> As said above, works perfectly. Could you commit it?

Commited :)
--=20
Iago Rubio  =20
- Home page    * http://www.iagorubio.com=20
- Last project * http://cssed.sourceforge.net        =20
- GPG Keyserv  * pgp.rediris.es id=3D0x909BD4DD