cssed-devel — cssed development discussion

[cssed-devel] Changes in the cssed 0.3.0 release

[<mic...@ea...>]

Could it be possible to change the title of the plugins dialog window,=20=

from:
plugins dialog
to:
Plugins dialog

and regenrate the po files and pot files accordingly (a fuzzy string=20
presumably in po files after regenerating the pot file).

That's just because all dialogs have a title with first letter=20
capitalzed, just to be consistent.

Mich=E8le
<http://micmacfr.homeunix.org>=

[cssed-devel] findinfiles plugin: changes

[<mic...@ea...>]

I've changes the plugin name in findinfiles.c, so that it appears as 
the other in cssed plugins dialog. po and pot files updated 
accordingly.

Here's the diff:

[cssed-devel] Changes in the 0.3.0 release (2)

[<mic...@ea...>]

Would it be possible to exchange the location the cancel and ok button=20=

in the selector wizard, just to be consistent throughtout the UI with=20
all other dialogs, where there is first cancel, then ok buttons.

Mich=E8le
<http://micmacfr.homeunix.org>=

[cssed-devel] Changes in the 0.3.0 release

[<mic...@ea...>]

Hi Iago,

Did you make those changes in cvs for the 0.3.0 release?

1 - Remove the close all icon in the file menu

2 - Add the Ctrl-Z shortcut to the Edit menu for undo, since it works=20
(reported earlier for the 0.2.1 release: Jun, 16th  Some bugs from=20
2.1).

3 - Change the name of Encoding to Force encoding in the Document menu

I need them for the doc.

Mich=E8le
<http://micmacfr.homeunix.org>=

Re: [cssed-devel] Problems with encoding changes

[<mic...@ea...>]

Le 25 sept. 2004, =E0 19:34, Iago Rubio a =E9crit :

>> Maybe, but better force encoding :-)
> Upsh ! Sure :)
>
> Do you think we must change the name ?
Yes, because it is very confusing. The user should be aware he may=20
spoil his file if he uses this without thinking first about it.
With Force encoding, or something like that, it is clear that it is not=20=

a "normal" way of doing it.
Maybe a tooltip on the menu items to tell the user that he should use=20
it before writing anithing in the document or something like that would=20=

be useful too.

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] Problems with encoding changes

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

On Fri, 2004-09-24 at 19:04, Mich=C3=A8le Garoche wrote:
> Le 24 sept. 2004, =C3=A0 18:47, Iago Rubio a =C3=A9crit :
>=20
> > On Fri, 2004-09-24 at 10:14, Mich=C3=A8le Garoche wrote:
> >> Say I write down a file with no special encoding.
> >
> > ok.
> >
> >> I put Mich=C3=A8le in it: (e grave on the first e).
> >> Then I save the file.
> >>
> >> Then I change the encoding to utf8, with Document->Encoding,
> >
> > Nope, you forze the buffer to be treated as UTF-8, it does not change
> > the encoding, nor convert between encodings.
> >
> > All text in the buffer will be in the file's encoding, and all new text
> > in the  selected encoding.
> >
> >> it leads
> >> to the loss of all characters after Mich (on the display at least).
> >> That's annoying.
[snip]
> > So the encoding is treated trasparently, but can not convert between
> > encodings yet.
> >
> > So ... what the hell is needed the anoying "Encoding" stuff ?
> No, I find it perfect. That's not annoying at all. Just people should=20
> know how it works.

Yes, you're right.

> > It's needed because cssed will treat all documents as UTF-8. If you=20
> > need
> > to write a document to anyone that can not read UTF-8, you can forze=20
> > the
> > encoding - before to write any text - and save in you preferred
> > encoding.
> >
> > I think that will be better to rename it as "Forze encoding" or
> > something like that.
> Maybe, but better force encoding :-)
Upsh ! Sure :)

Do you think we must change the name ?
--=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

Re: [cssed-devel] Problems with encoding changes

[<mic...@ea...>]

Le 24 sept. 2004, =E0 18:47, Iago Rubio a =E9crit :

> On Fri, 2004-09-24 at 10:14, Mich=E8le Garoche wrote:
>> Say I write down a file with no special encoding.
>
> ok.
>
>> I put Mich=E8le in it: (e grave on the first e).
>> Then I save the file.
>>
>> Then I change the encoding to utf8, with Document->Encoding,
>
> Nope, you forze the buffer to be treated as UTF-8, it does not change
> the encoding, nor convert between encodings.
>
> All text in the buffer will be in the file's encoding, and all new =
text
> in the  selected encoding.
>
>> it leads
>> to the loss of all characters after Mich (on the display at least).
>> That's annoying.
>
> I know that :)
>
> It handles the encodings well, but you - right now - can not convert
> between different encodings in cssed. It'll recognize the encoding of
> opened files and set as UTF-8 the new ones, but can not convert.
>
> As example, try `file` on your file with "Mich=E8lle", imagine you =
named
> it "test".
>
> It will say you something like:
> $file test
> test: ISO-8859 text, with no line terminators
>
> Open it in cssed, add more text and save it.
>
> Then try `file`again, it will be still ISO-8859.
>
> Now convert it to UTF-8 with:
> $iconv -f ISO-8859-1 -t UTF-8 test > test.utf8
> $file test.utf8
> test.utf8: UTF-8 Unicode text, with no line terminators
>
> Open test.utf8 in cssed, add more text and save it. It will recognice=20=

> it
> as UTF-8, the encoding will be set automatically and the text will be
> saved as UTF-8 (try file again if you want to check if it's true).
>
> So the encoding is treated trasparently, but can not convert between
> encodings yet.
>
> So ... what the hell is needed the anoying "Encoding" stuff ?
No, I find it perfect. That's not annoying at all. Just people should=20
know how it works.

>
> It's needed because cssed will treat all documents as UTF-8. If you=20
> need
> to write a document to anyone that can not read UTF-8, you can forze=20=

> the
> encoding - before to write any text - and save in you preferred
> encoding.
>
> I think that will be better to rename it as "Forze encoding" or
> something like that.
Maybe, but better force encoding :-)

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] Test packages 0.3.0

[<mic...@ea...>]

Le 24 sept. 2004, =E0 18:17, Iago Rubio a =E9crit :
>> Some questions:
>>
>> Encoding->Default: what is it? (utf-8, defined by the user, picked=20
>> from
>> the file extension, or other?)
>
> Usually an ISO-##### encoding.
>
>> Encoding->others (utf8, dbcs): does it change the encoding of the =
file
>> or just the display in cssed?
>
> It will not change the current buffer but will set this encoding for=20=

> all
> incoming text.
>
> How it's work is simple:
>
> - Any blank document will be set as UTF-8 and saved as UTF-8.
>
> - If you don't want it to be UTF-8, select another encoding before to
> write any text.
>
> - When a given document is opened, if it's in UTF-8 it will be
> recognized and set as UTF-8.
>
> - If it's not valid UTF-8 it will be set to the best match ISO-####
> code.
>
> - If you want to write JIS (japanese) or Hangul you must forze to DBCS
> on each document you'll open and on each new document.
>
> This entry should be called "Forze encoding".
>
> Right now cssed will handle UTF-8/ISO text transparently and DBCS
> forzed.
>
> The default file encoding is UTF-8.
>
> To forze ISO code as UTF-8 will result in bad rendering in the =
display,
> and the same if is forzed UTF-8 code to ISO.
>
> Just try it:
> 1.- Create a blank document, use accenter characters and save it. The
> use "file" to know the encoding on disk, it should tell you UTF-8 as
> it's the default.
>
> Something like:
> $file test
> test: UTF-8 Unicode text
>
> 2.-  Create a blank document,forze to default, use accenter characters
> and save it. Then use file again and it should tell you the encoding =
is
> ISO-bhla_bhla.
>
> Something like:
> $ file test
> test: ISO-8859 text
>
> 3.- Open an UTF-8 file, change the text and save it again.
> It should be in UTF-8.
>
> 4.- Open an ISO-#### file, change the text and save it again.
> It should be ISO-######.
>
> Take into account that if you take out all accented characters in the
> text, it will be recogniced always as ASCII by file.
>
> It will not convert between encodings. If you opens UTF-8 and forzes
> ISO, It will end in bad rendering.
>
> Does it helped or still confused ??
That's just perfect, will write this down in the doc, since it is not=20
obvious.

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] Problems with encoding changes

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

On Fri, 2004-09-24 at 10:14, Mich=C3=A8le Garoche wrote:
> Say I write down a file with no special encoding.

ok.

> I put Mich=C3=A8le in it: (e grave on the first e).
> Then I save the file.
>=20
> Then I change the encoding to utf8, with Document->Encoding,=20

Nope, you forze the buffer to be treated as UTF-8, it does not change
the encoding, nor convert between encodings.

All text in the buffer will be in the file's encoding, and all new text
in the  selected encoding.

> it leads=20
> to the loss of all characters after Mich (on the display at least).
> That's annoying.

I know that :)

It handles the encodings well, but you - right now - can not convert
between different encodings in cssed. It'll recognize the encoding of
opened files and set as UTF-8 the new ones, but can not convert.

As example, try `file` on your file with "Mich=C3=A8lle", imagine you named
it "test".

It will say you something like:
$file test
test: ISO-8859 text, with no line terminators

Open it in cssed, add more text and save it.=20

Then try `file`again, it will be still ISO-8859.

Now convert it to UTF-8 with:
$iconv -f ISO-8859-1 -t UTF-8 test > test.utf8
$file test.utf8
test.utf8: UTF-8 Unicode text, with no line terminators

Open test.utf8 in cssed, add more text and save it. It will recognice it
as UTF-8, the encoding will be set automatically and the text will be
saved as UTF-8 (try file again if you want to check if it's true).

So the encoding is treated trasparently, but can not convert between
encodings yet.

So ... what the hell is needed the anoying "Encoding" stuff ?

It's needed because cssed will treat all documents as UTF-8. If you need
to write a document to anyone that can not read UTF-8, you can forze the
encoding - before to write any text - and save in you preferred
encoding.

I think that will be better to rename it as "Forze encoding" or
something like that.

--=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

Re: [cssed-devel] Test packages 0.3.0

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

On Fri, 2004-09-24 at 10:01, Mich=C3=A8le Garoche wrote:
> Le 24 sept. 2004, =C3=A0 9:51, Iago Rubio a =C3=A9crit :
> > On Fri, 2004-09-24 at 04:23, Mich=C3=A8le Garoche wrote:
> >> Do you mean you have changed the build scripts versus cvs?
> > No, I've no changed them and will not change until the release. Right
> > now they're frozen.
> OK, perfect, when completely done, could you load somewwhere the=20
> definitive packages (but not on the web site, otherwise, people as=20
> likely to download them), so that I test them as if I dowload them (not=20
> from cvs).

I will upload it to your box and mail you.

> >>> The source tree is the CVS one.
> >>> I'm working now in the BSD port and Debian packages,
> >>> I hope we'll release this week-end :)
> >> Hope the doc is finished by this time :-) Deadline? Sunday 23 hours?
> > If it's a big workload for you, or you need more time for the doc, we
> > can wait.
> I'll think it will be ok, but well, I discover some glitches while=20
> making the doc, so that's may delay a bit.

Don't worry about the delay.=20

> Some questions:
>=20
> Encoding->Default: what is it? (utf-8, defined by the user, picked from=20
> the file extension, or other?)

Usually an ISO-##### encoding.

> Encoding->others (utf8, dbcs): does it change the encoding of the file=20
> or just the display in cssed?

It will not change the current buffer but will set this encoding for all
incoming text.

How it's work is simple:

- Any blank document will be set as UTF-8 and saved as UTF-8.

- If you don't want it to be UTF-8, select another encoding before to
write any text.

- When a given document is opened, if it's in UTF-8 it will be
recognized and set as UTF-8.

- If it's not valid UTF-8 it will be set to the best match ISO-####
code.

- If you want to write JIS (japanese) or Hangul you must forze to DBCS
on each document you'll open and on each new document.

This entry should be called "Forze encoding".

Right now cssed will handle UTF-8/ISO text transparently and DBCS
forzed.

The default file encoding is UTF-8.

To forze ISO code as UTF-8 will result in bad rendering in the display,
and the same if is forzed UTF-8 code to ISO.

Just try it:
1.- Create a blank document, use accenter characters and save it. The
use "file" to know the encoding on disk, it should tell you UTF-8 as
it's the default.=20

Something like:
$file test
test: UTF-8 Unicode text

2.-  Create a blank document,forze to default, use accenter characters
and save it. Then use file again and it should tell you the encoding is
ISO-bhla_bhla.=20

Something like:
$ file test
test: ISO-8859 text

3.- Open an UTF-8 file, change the text and save it again.=20
It should be in UTF-8.

4.- Open an ISO-#### file, change the text and save it again.
It should be ISO-######.

Take into account that if you take out all accented characters in the
text, it will be recogniced always as ASCII by file.

It will not convert between encodings. If you opens UTF-8 and forzes
ISO, It will end in bad rendering.

Does it helped or still confused ??
--=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

[cssed-devel] Problems with encoding changes

[<mic...@ea...>]

Say I write down a file with no special encoding.

I put Mich=E8le in it: (e grave on the first e).

Then I save the file.

Then I change the encoding to utf8, with Document->Encoding, it leads=20
to the loss of all characters after Mich (on the display at least).

That's annoying.

Mich=E8le
<http://micmacfr.homeunix.org>=

Re: [cssed-devel] Test packages 0.3.0

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

On Fri, 2004-09-24 at 04:32, Mich=C3=A8le Garoche wrote:
> Le 23 sept. 2004, =C3=A0 20:53, Iago Rubio a =C3=A9crit :
>=20
> > I'm making some test packages now the Win32 port is done - but no
> > plugins yet - and I've uploaded them to my web site.
> There is nothing but the po files in cssed-0.30.tar.gz, is it intended=20
> as is?

I've used a new script to clean all uneeded files. May be it taken out
the gmo files as they're bulild on "make install".

If you need them I will change it. Please let me know.

> And for filebrowser, just the po, readme and a makefile

It's a bug. I will repackage it.

> There is an error on decompressing find-in-files plugin. Then the=20
> source is missing. Idem for quicksearch (error on decompressing).

Checking the files I see size mismatches between my local copy and the
site so It seems that some file hot corrupted in the upload ( It seems
as if I used ASC mode ?? ).

I will upload them again.

> So that I cannot test anything.

Please try to download again the corrupted packages, and report any
changes you think should be done.=20

Thanks in advance.
--=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

Re: [cssed-devel] Same icon for close and close all menu items

[<mic...@ea...>]

Le 24 sept. 2004, =E0 10:04, Iago Rubio a =E9crit :

> On Fri, 2004-09-24 at 07:48, Mich=E8le Garoche wrote:
>> Hi Iago,
>> Do you have the same icon for close and close all in the file menu?
>> Is this kind of bug in glade?
> No, it's there's no stock "close-all" icon, so I used the same icon.=20=

> The
> same apply for "Save" and "Save all" :(
> May be I should take them out.
Yes, it would be better, because it is confusing.

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] Same icon for close and close all menu items

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

On Fri, 2004-09-24 at 07:48, Mich=C3=A8le Garoche wrote:
> Hi Iago,
>=20
> Do you have the same icon for close and close all in the file menu?
>=20
> Is this kind of bug in glade?

No, it's there's no stock "close-all" icon, so I used the same icon. The
same apply for "Save" and "Save all" :(

May be I should take them out.
--=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

Re: [cssed-devel] Test packages 0.3.0

[<mic...@ea...>]

Le 24 sept. 2004, =E0 9:51, Iago Rubio a =E9crit :

> On Fri, 2004-09-24 at 04:23, Mich=E8le Garoche wrote:
>> Le 23 sept. 2004, =E0 20:53, Iago Rubio a =E9crit :
>>> I'm making some test packages now the Win32 port is done - but no
>>> plugins yet - and I've uploaded them to my web site.
>>>
>>> http://www.iagorubio.com/cssed-test-0.3.0/
>> Do you plan to let the dot and the slash before the name, it's very
>> unusual and could lead to confusion on the mac (interpreted as
>> invisible files).
> It's just the server address "./" =3D "this directory".
OK, perfect.

>>> The sources could change a little, but the build scripts, and=20
>>> packaging
>>> scripts won't change if no errors are found.
>> Do you mean you have changed the build scripts versus cvs?
> No, I've no changed them and will not change until the release. Right
> now they're frozen.
OK, perfect, when completely done, could you load somewwhere the=20
definitive packages (but not on the web site, otherwise, people as=20
likely to download them), so that I test them as if I dowload them (not=20=

from cvs).

>
>>> The source tree is the CVS one.
>>> I'm working now in the BSD port and Debian packages,
>>> I hope we'll release this week-end :)
>> Hope the doc is finished by this time :-) Deadline? Sunday 23 hours?
> If it's a big workload for you, or you need more time for the doc, we
> can wait.
I'll think it will be ok, but well, I discover some glitches while=20
making the doc, so that's may delay a bit.

Some questions:

Encoding->Default: what is it? (utf-8, defined by the user, picked from=20=

the file extension, or other?)
Encoding->others (utf8, dbcs): does it change the encoding of the file=20=

or just the display in cssed?

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] Test packages 0.3.0

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

On Fri, 2004-09-24 at 04:23, Mich=C3=A8le Garoche wrote:
> Le 23 sept. 2004, =C3=A0 20:53, Iago Rubio a =C3=A9crit :
>=20
> > I'm making some test packages now the Win32 port is done - but no
> > plugins yet - and I've uploaded them to my web site.
> >
> > http://www.iagorubio.com/cssed-test-0.3.0/
> Do you plan to let the dot and the slash before the name, it's very=20
> unusual and could lead to confusion on the mac (interpreted as=20
> invisible files).

It's just the server address "./" =3D "this directory".

> > The sources could change a little, but the build scripts, and packaging
> > scripts won't change if no errors are found.
> Do you mean you have changed the build scripts versus cvs?

No, I've no changed them and will not change until the release. Right
now they're frozen.

> > The source tree is the CVS one.
> > I'm working now in the BSD port and Debian packages,
> > I hope we'll release this week-end :)
> Hope the doc is finished by this time :-) Deadline? Sunday 23 hours?

If it's a big workload for you, or you need more time for the doc, we
can wait.

I'll try to have all packaging solved this week-end. We'll no release
until the doc have been finished.=20

Just tell me when you think you're ready :)

Don't worry if you need more time, we can wait another week if necesary
(or even more time if it's needed).
--=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

[cssed-devel] Same icon for Save and Save all

[<mic...@ea...>]

This is the same for Save and Save all icons in the file menu.

This is very confusing.

Mich=E8le
<http://micmacfr.homeunix.org>=

[cssed-devel] Same icon for close and close all menu items

[<mic...@ea...>]

Hi Iago,

Do you have the same icon for close and close all in the file menu?

Is this kind of bug in glade?

Mich=E8le
<http://micmacfr.homeunix.org>=

Re: [cssed-devel] Test packages 0.3.0

[<mic...@ea...>]

Le 23 sept. 2004, =E0 20:53, Iago Rubio a =E9crit :

> I'm making some test packages now the Win32 port is done - but no
> plugins yet - and I've uploaded them to my web site.
There is nothing but the po files in cssed-0.30.tar.gz, is it intended=20=

as is?

And for filebrowser, just the po, readme and a makefile

There is an error on decompressing find-in-files plugin. Then the=20
source is missing. Idem for quicksearch (error on decompressing).

So that I cannot test anything.

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] Test packages 0.3.0

[<mic...@ea...>]

Le 23 sept. 2004, =E0 20:53, Iago Rubio a =E9crit :

> I'm making some test packages now the Win32 port is done - but no
> plugins yet - and I've uploaded them to my web site.
>
> http://www.iagorubio.com/cssed-test-0.3.0/
Do you plan to let the dot and the slash before the name, it's very=20
unusual and could lead to confusion on the mac (interpreted as=20
invisible files).

> The sources could change a little, but the build scripts, and =
packaging
> scripts won't change if no errors are found.
Do you mean you have changed the build scripts versus cvs?
>
> The source tree is the CVS one.
> I'm working now in the BSD port and Debian packages,
> I hope we'll release this week-end :)
Hope the doc is finished by this time :-) Deadline? Sunday 23 hours?

Mich=E8le
<http://micmacfr.homeunix.org>

[cssed-devel] Test packages 0.3.0

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

I'm making some test packages now the Win32 port is done - but no
plugins yet - and I've uploaded them to my web site.

http://www.iagorubio.com/cssed-test-0.3.0/

The sources could change a little, but the build scripts, and packaging
scripts won't change if no errors are found.

The source tree is the CVS one.
=20
I'm working now in the BSD port and Debian packages,=20

I hope we'll release this week-end :)
--=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

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

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

On Wed, 2004-09-22 at 11:47, Mich=C3=A8le Garoche wrote:
> Le 22 sept. 2004, =C3=A0 11:38, Iago Rubio a =C3=A9crit :
> >>> I also expect more menu based plugins when I fix menu access, and=20
> >>> more
> >>> non ui plugins as file managers and css dialogs.
> >> Yes, of course, but anyway, all plugins must follow the principle that
> >> 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.
> OK, did you commit it?

No, I'm working in the Win32 port - almost done, changes in CVS - and
can not change the two source trees at the same time.

If cssed fits in 800x600 no change will be done before the release. If
doesn't fits in 800x600, will go for the quickest/easiest solution,
instead of rewritting the GUI.

The next release will fix all those issues.

> > 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=20
> > 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.
> > 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.
> > What I don't want to do, is to waste resources checking the length of
> > the screen at any window move/resize.
> Oh, yes, that's too complicated. But if we limit the check to our=20
> 640*800 screen,
Wow !!!

	+----------+
	|          |
	|          |
	|          |
	|          |
	|          |
	|          |
	+----------+

Really strange screens on Macs ;))

> would not it be sufficient? I mean build the toolbars=20
> so that it fits on 640*800. Then no check in code while running.

If we make it fit in the minimun expected resolution (640x480 in our
case). It will be OK, but users of longer screens will see cuted/small
toolbars and a bunch of them.

If we read the resolution on startup and fits the toolbars on it, when
the user moves the windows to another screen it will not fit if it have
a different resolution.

I must think on it.

Right now, the goal for me is to acomodate the main window on < 800x600.
--=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

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

[<mic...@ea...>]

Le 22 sept. 2004, =E0 11:38, Iago Rubio a =E9crit :
> On Wed, 2004-09-22 at 02:57, Mich=E8le Garoche wrote:
>> Le 21 sept. 2004, =E0 20:08, Iago Rubio a =E9crit :
> Yes, all plugins in CVS should load ok. Third party one must work on =
it
> their own ;)
Yes, of course, just a note in plugin doc would be sufficient.

>>> I also expect more menu based plugins when I fix menu access, and=20
>>> more
>>> non ui plugins as file managers and css dialogs.
>> Yes, of course, but anyway, all plugins must follow the principle =
that
>> 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.
OK, did you commit it?

> 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=20
> 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.
> 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.
> What I don't want to do, is to waste resources checking the length of
> the screen at any window move/resize.
Oh, yes, that's too complicated. But if we limit the check to our=20
640*800 screen, would not it be sufficient? I mean build the toolbars=20
so that it fits on 640*800. Then no check in code while running.

Mich=E8le
<http://micmacfr.homeunix.org>

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

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

[<mic...@ea...>]

Le 21 sept. 2004, à 20:08, Iago Rubio a écrit :

> On Tue, 2004-09-21 at 13:02, Michèle Garoche wrote:
>> Le 21 sept. 2004, à 12:42, Iago Rubio a écrit :
> [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 
50*7 for the terminal, now it's ok.

>>> 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 
> -
> I think - in 800x600.
It works perfectly here also.

>> 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 
exceeding the screen width.
Here's a screenshot, the height is perfect, all plugins are loaded, 
what is missing is the two icons for hiding panels and the preferences 
icon in first toolbar, then the quicksearch search field and its two 
backward/forward search icons in the second toolbar.