Re: GUII pixmaps
On Fri, 18 Aug 2000, Dekel Tsur wrote: Imagemagick also support transformation (e.g. convert -rotate 30), and it can convert from eps to any format (using gs). It also include a shared library (libmagick). I'm not sure how useful it is for your purposes, but I'll leave it to you to do the research :) I know about ImageMagick, I intend to support it, but I think it is better to use ghostscript which every LyX user currently have already, I'll add ImageMagick has a second backup, possibly a better solution than gs, but first I want to have backward compatiblity with former lyx versions. PS: I still think that you should try making the image viewing be done without creating temporary XPM (or other) files (after the image is converted to a format readable by (pdf)latex, i.e. eps/pdf/png/jpeg). I wouldn't mind doing such a thing, however I cannot figure how to do it. If you have any idea I'd like to hear about it. Note that Lars(?) asked me to avoid using the ghostscript x11 driver so the way it is done currently is unwanted. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers ADD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: GUII pixmaps
On Thu, 17 Aug 2000, Garst R. Reese wrote: Dekel Tsur wrote: On Thu, Aug 17, 2000 at 09:44:48AM +0300, Baruch Even wrote: On 17 Aug 2000, Miyata Shigeru wrote: Lastly for linear transform of a graphic buffer of X, we may adopt libart http://www.levien.com/libart/ I'll check it out too, however I was told to avoid adding dependencies, so I'll have to support ghostscript as a transformer and libxpm as a loader to make sure that everything will continue to work, even though I think it will still require an added dependency on ImageMagick or something else to transfer between png and xpm. Imagemagick also support transformation (e.g. convert -rotate 30), and it can convert from eps to any format (using gs). It also include a shared library (libmagick). I'm not sure how useful it is for your purposes, but I'll leave it to you to do the research :) PS: I still think that you should try making the image viewing be done without creating temporary XPM (or other) files (after the image is converted to a format readable by (pdf)latex, i.e. eps/pdf/png/jpeg). It might be useful to poll the dev and user lists to determine what they already have installed. Other things else I have require Imagemagick, imlib,libpng, and libart, so it is hard to imagine that anything that lyx wants is going to be a problem. The gnome stuff is so incredibly heavy that I think worrrying about this issue is futile. Especially after teTeX and ghostscript. Garst I don't think that this things will be a problem to add, but if I can avoid ADDING DEPENDENCIES I'd rather do that. Thus I'll support initially the ghostscript method, hopefully without the need for ImageMagic. And then I can add additional methods that will complement and improve on the basic, this way I'll be assured that former users can continue to use LyX without new installations, and that everyone will be able to benefit from the additional features if the only install (or already have) some additional dependencies. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers ADD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: Suggestion on FormTabular: Cell cettings and multicol
On Thu, 17 Aug 2000, Baruch Even wrote: On 17 Aug 2000, Lars Gullik Bjønnes wrote: Baruch Even [EMAIL PROTECTED] writes: | It might be a good idea to release soon a lyx-1.1.6-beta1 in order to do | the testing by those who will need to use the code. It would be a bad idea | to release so much new code without having some brave users test it | beforehand, We always have at lest three prereleases if tere have been a lot of changes, so the questions if we should push forward and go direcly for the 1.2.0 goal, or stop up a bit and release 1.1.6pre1 (and we have work that is needed for that too...), if we don't release a 1.1.6pre we enable the NEW_TABULAR and NEW_INSETS wait a bit, fix stuff implement some, and release a 1.2.0pre1 My vote: 1.1.6 then 1.2.0 We have gone long enough without a prerelease. If we switch to the comparatively untested NEW_[EVERYTHING] stuff¹ we are likely to slow down development excessively I feel. At least with the mostly old stuff in place we know a lot of it is "stable". Then 1.1.6 can be completed and we can do a proper job of 1.2.0. Fixing all the other intermediate problems as we go. So we end up doing all the same work but at least get more people using at least one of the releases (1.1.6). ¹ Lars issued a challenge, I published it in LDN and almost none responded. I think that taking a break now will be a good idea, we could then try to aim for better support for GUII in 1.2.0, as far as I looked into it, it will require quite a bit of work to get LyX fully GUII, quite a bit of its internals are dependent on X windows calls. There's GUII and SI (System Independence). X is used on all the Unix platforms and keeps us going on Windows and OS/2. Lets get the GUI independent of toolkits first (but still dependent on X) and then get independent of X. That doesn't mean we should ignore SI issues just that we concentrate on sweeping the floor [removing xforms/toolkit code from the core] before we polish it [make it shine ;-)]. For 1.2.0 I'd be happy to have most of the dialogs in all three toolkit ports. We don't need all of them but it would certainly make a nice milestone for 1.2.0 to be toolkit agnostic. Then 1.x.0 (x =3; probably x3) can be the SI or XI target. These thoughts are also due to the number of people who will still be thinking in Linux-kernel numbering instead of just-another-release numbering. [imlib dependency] I'd rather do without inline rendering until later and have you work on all those other things you listed. Allan. (ARRae)
Re: Suggestion on FormTabular: Cell cettings and multicol
On 17-Aug-2000 Lars Gullik Bjønnes wrote: NEW_INSETS should be enabled at the same time, because: - keep the fileformat changes localized to on version - they also use the textinsets and the other insets that tabular uses, better testing. - deveopment for 1.3.0 will be a lot cleaner since we can remove a lot of cruft intermixing table/flotat code. - why should you get your code in and I not mine? Well to answer you what I think: - the fileformat will change and change again between version, as we will change stuff and add new features, so this is bogus. - better testing I agree completely - well as we will have a 1.1.6 then 1.2.0 development until 1.3.0 will pass quite some time - and to this I only have to say that probably I won't include more of mine work then of your work! InsetCollapsable is the base for all other text-based insets we made till now which are really only derived insets! Why activate NEW_TABULAR and not NEW_INSETS: - new tabular is mainly finished, there are some problems (mainly with mouse selection) and maybe some behaviours user don't like so much, but I regard it a feature complete! This is the only table code I will support from now on, there is lot's of stuff User asked for in a long time and we could give the user a first impression of the new stuff we will make available in the next version after 1.1.6 (1.2.0). - We have still quite a lot of problems to resolve with other insets, especially your baby the minipage inset is just there to be there it's the same as a foot inset without more support and there is a lot of work to do to make this work so we would have to stale the release of a 1.1.6pre1 just to make all the changes necessary to implement minipages in clean way. - Not only that but we also have to resolve the problems in reading all the right stuff from dummy paragraphs into the right text-inset, which is IMO also quite a bit of work. So you see while the tabular-inset IS ready for prime-time most (it reads all old code correct I tried this with various files and also the UserGuide!) the other text inset still need lot's of work. If we decide for 1.2.0 I will enable NEW_TABULAR and NEW_INSETS right away. And then you will get some testing. Also at once when we have the remaining bits in place we will release 1.2.0pre1 and you will probably get even more testing then. No I think we should release a 1.1.6 before, we can have a vote if and what we want to activate if all core developer (Note: this is a decission ONLY now working developers can take, this includes all of you sending regular patches and who took up a part of the sourcetree for their responsability!). My vote is 1.1.6 with ONLY NEW_TABULAR activated! It does not seem to be quite equivalent with the old code, at least some warnings are missing wen you switch document classes. It also seems to me that the new document defaults are not set. Yes I've seen that warnings are not put out and I investigate that, but the documents defaults ARE set I tried that, well I will put #ifdef stuff around the old code so we'll see what will fall away and if it works when it is not anymore there. Jürgen P.S.: You still didn't say if you like the new layout or if you would like it some other way ;) -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Duct tape is like the force. It has a light side, and a dark side, and it holds the universe together ... -- Carl Zwanzig
Re: The external inset once again (was: user-feedback on 116cvs)
On 17-Aug-2000 Asger K. Alstrup Nielsen wrote: Juergen has demonstrated this nicely with his excellent work on the new tabular inset. Btw, I hope people appreciate the excellent work Juergen and Lars are doing with the text insets. Their work is very much related to infrastructure, and therefore not as immediately visible as much of the other excellent work being done on the GUII, i18n, and more. I'm not trying to tone down the importance of this other work, but I'd just like to publically pad these guys on their back and say: Good work, have a beer! And while we are at it, you other guys can have one as well. Well I have to admit to hear this from you feels good #:O) And I had a beer yesterday on this! #:O) Jürgen P.S.: And it was a lot of work, after the FILM I worked more or less 4-5 hours a day on lyx to complete all the work we stared there. -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Non-sequiturs make me eat lampshades.
Re: Changing tabular multirow latex output!
On 17-Aug-2000 Bernd Paysan wrote: I'm using latext CVS (i.e. the bug report is related to insettabular.C rev. 1.44, Aug 11). I'll give a more detailed bug report in the following lines: For now thanks for the report I will replay to the single points when I find the time to have a look, but you're report will surely help to make tabular-insetes even better! Greets Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The Phone Booth Rule: A lone dime always gets the number nearly right.
Re: Suggestion on FormTabular: Cell cettings and multicol
On Fri, 18 Aug 2000, Allan Rae wrote: I think that taking a break now will be a good idea, we could then try to aim for better support for GUII in 1.2.0, as far as I looked into it, it will require quite a bit of work to get LyX fully GUII, quite a bit of its internals are dependent on X windows calls. There's GUII and SI (System Independence). X is used on all the Unix platforms and keeps us going on Windows and OS/2. Lets get the GUI independent of toolkits first (but still dependent on X) and then get independent of X. That doesn't mean we should ignore SI issues just that we concentrate on sweeping the floor [removing xforms/toolkit code from the core] before we polish it [make it shine ;-)]. I thought GUII to include SI, and think that we should go at the 1.2.0 level on a sweeping work to move everything X or Toolkit dependent to other classes. The work itself to create a Windows/OS2/Mac/BeOS/Commodore64 version of LyX probably wouldn't be done so fast anyhow. But the localization of everything frontend related in the frontends directory/domain is a very good idea IMHO. For 1.2.0 I'd be happy to have most of the dialogs in all three toolkit ports. We don't need all of them but it would certainly make a nice milestone for 1.2.0 to be toolkit agnostic. Then 1.x.0 (x =3; probably x3) can be the SI or XI target. In any way that you look at it, in order to be really toolkit agnostic you'll need to seperate the frontend from the core. Otherwise you'll have trouble LyX work completely in a single toolkit, as opposed to now that the Gnome/KDE ports are part Native part XForms, I know the problem of porting all dialogs to the toolkit, it takes time, but the main app itself is not portable, even though there is a move toward it with the toolbars and the mainmenu. [imlib dependency] I'd rather do without inline rendering until later and have you work on all those other things you listed. I actually consider the inline rendering a must before going to the wild word of creeping freaturism. Inline rendering is expected anywhere a graphics is embedded, it will be important also to the External/Graphics Inset combination, and is as far as I can see it the main reason why I wouldn't suggest replacing the FigInset with the GraphicsInset at this time. Adding features to the GI will not be too hard a task, many things that can be added are pretty simple to do, some others are more elaborate, but I do think that none of them is in the order of the inline rendering. Besides the inline rendering as it is developed now will give me the tool for a freeping creature, Having thumbnails in the image file chooser, that will be a neat feature (freeping creaturism or not?! :-) -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers ADD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
LyXImage patch
Attached again is the LyXImage patch, there were some updates to the tree and it is (for) now against the latest CVS. I won't be here till at least tuesday and possibly all of next week, if you find any trouble with the patch don't apply it as I won't be able to have a good response, I'll try to stay connected and working during this time but as I said, the machine there is not suitable for development. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers ADD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael patch.gz
insettabular: double lines
While testing the new tabular inset, I realized that in some cases LaTeX will make a double line where the tabular inset only displays a single. To reproduce this, one has to mark two cells which lie side by side both multicol, then assign a right border line to the left one and a left border line to the right one. Timm
Re: [PATCH] KDE FormUrl
On Thu, 17 Aug 2000, Allan Rae wrote: 1) As I pointed out, layout isn't handled by kdlgedit. So this doesn't use it. Is this OK ? Is this the geometry stuff you were referring to for the copyright dialog? Yes. I actually had a mail over the weekend from someone who implied Qt Designer can generate Qt 1.1 only code, which wasn't at all clear from the tarball of Qt 2.2.beta. If this is true, then we can switch to using that, and everyone is happy :) [23 will have to wait till I have time to read the code and figure out what you are talking about...] 4) I wasn't sure about using ButtonPolicies as i've not examined that code yet (STL still looks like line noise to me i'm afraid :() With a vector implementation it should look like a two dimensional array. You have to write your own version of ButtonController that works with Qt/KDE buttons in the same manner that xforms/ButtonController.h does. The STL code used is pretty simple. So just look at what ButtonController does and don't worry about the implementation of ButtonPolicies. Just worry about which button policy is appropriate for a given dialog. Also don't feel that you _have_ to use the existing policies. If KDE has different ideas about what an applicxation should do with its buttons then maybe implement OK, that's good. I think it might be useful anyway, I'll look at this. Or better yet try using a status variable as defined in DialogBase.h. Even better would be to use the appropriate policy from button policy. I'm thinking about adding a "listFL_OBJECT read_only;" to ButtonController so that we can push all the widgets we want disabled on a read-only status (or some other status as defined by the policy) into the list and then not have to worry about handling de/activation separately. Allan. (ARRae) yes, a button policy seems to be the way to go on this. Note in kde/ I hide the "OK" button, and make Cancel "Close". This seems a more sensible presentation to the user ... thanks Allan ! john -- "The path you specified contains too many directories. Delete one or more directories or clear the Include Subdirectories checkbox." - Microsoft Office
RE: Gnome: FormToc FormIndex
not all are empty (diaprint_callbacks.c). Well, the rest are empty, that's true. In general, more complex dialogs will require some callbacks. I think that if we will remove these (empty) files then we will have to postprocess Glade-generated _interface files which include _callbacks. I guess the callbacks should go into the FormXxx files and so we can remove this additional files and yes we have to postprocess the .[ch] files I've seen that already, so if you move the callbacks you use into the FormXxx implementation I see then to get rid of the #includes in the interface files and we should make a Makefile in the dialogs-directory which can produce the right files and postprocess them automatically (if I'm not mistaken glade has some sort of export option at least I've seen this in the archimedes project) - would it be possible to postprocess the .[ch] files so that we can get .[Ch] files as we do with fdesign generated files? (I would help to implement this if you like it!) In all computers that I've seen, gcc compiles files faster than g++. Do we need to have compilation times longer? :) Well I let Allan or others explain why they would like .C files instead of .c files I'm not the expert here #:O) - what is this support.[ch] is it always generated by glade? yes. at least one function is used by me directly: lookup_widget. Yes but is this generated for each .glade file you process or do you have to call glade with some special option to process it? And does glade use this then or you have to use the functions for your implementation? This is much better implementation. Should I change it or you will make it? Well it's your baby :) - I will also have a look why some menu-items are never enabled and/or displayed wrong. Is it Gnome-specific or the same trouble is with XForms implementation? This is Gnome-specific, I had a look and there is some problem with the update of the menus. While in the xforms part the menu is rebuild when I press on a menu-button this does not happen in gnome. I will have a better look but you should try too as you know better than me how gnome-menus work ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ We don't believe in rheumatism and true love until after the first attack. -- Marie Ebner von Eschenbach
Re: [PATCH] KDE FormUrl
On Fri, 18 Aug 2000, John Levon wrote: Yes. I actually had a mail over the weekend from someone who implied Qt Designer can generate Qt 1.1 only code, which wasn't at all clear from the tarball of Qt 2.2.beta. If this is true, then we can switch to using that, and everyone is happy :) apologies for the post to self, but I got a reply from the guy and it seems I misunderstood him. The kdevelop branch can be used for both versions, but not Qt Designer. So it seems there isn't an available dialog editor :( Juergen, I tried *very* hard to use Qt Architect 1.4.4 to design FormIndex. It kept on breaking when I used layouts, making one of the buttons disappear, with no way of getting it back (except by editing the generated file, but that kind of defeats the point :). thanks john -- "The path you specified contains too many directories. Delete one or more directories or clear the Include Subdirectories checkbox." - Microsoft Office
Re: [PATCH] KDE FormUrl
apologies for the post to self, but I got a reply from the guy and it seems I misunderstood him. The kdevelop branch can be used for both versions, but not Qt Designer. So it seems there isn't an available dialog editor :( Well you tried ;) Juergen, I tried *very* hard to use Qt Architect 1.4.4 to design FormIndex. It kept on breaking when I used layouts, making one of the buttons disappear, with no way of getting it back (except by editing the generated file, but that kind of defeats the point :). Depends on what you had to change and how much work it was to change it! We could use 2 methods: 1. a general sed script (prefered) 2. a patch (as with some dialogs in the xforms tree) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ When in panic, fear and doubt, Drink in barrels, eat, and shout.
RE: Gnome: FormToc FormIndex
On Fri, 18 Aug 2000, Juergen Vigna wrote: I guess the callbacks should go into the FormXxx files and so we can remove this additional files and yes we have to postprocess the .[ch] files I've seen that already, so if you move the callbacks you use into the FormXxx implementation I see then to get rid of the #includes in the interface files and we should make a Makefile in the dialogs-directory which can produce the right files and postprocess them automatically (if I'm not mistaken glade has some sort of export option at least I've seen this in the archimedes project) I'll move the callbacks to FormXxx (actually, FormPrint is the only one that needs it). In all computers that I've seen, gcc compiles files faster than g++. Do we need to have compilation times longer? :) Well I let Allan or others explain why they would like .C files instead of .c files I'm not the expert here #:O) I'm eager to hear it. Or is it FAQ-type question and I should look into developers-FAQ? - what is this support.[ch] is it always generated by glade? yes. at least one function is used by me directly: lookup_widget. Yes but is this generated for each .glade file you process or do you have to call glade with some special option to process it? And does glade use this then or you have to use the functions for your implementation? Generally, glade produces this file for every project. However, as far as I have seen it is almost identical each time. You can desire not to produce this file, but Glade assumes that you have one in the code it produces. And there is at least one function which is really required by my implementation: lookup_widget. This is much better implementation. Should I change it or you will make it? Well it's your baby :) I'll patch it. This is Gnome-specific, I had a look and there is some problem with the update of the menus. While in the xforms part the menu is rebuild when I press on a menu-button this does not happen in gnome. I will have a better look but you should try too as you know better than me how gnome-menus work ;) I think that the problem is in the way LyX calls "update" function. For example, when I press "Undo" in the menu, the "Redo" command is still disabled. I have to move and click mouse in LyX working area to get it enabled. I would predict, that the toolbar should have the similar behavior. Marko
RE: Gnome: FormToc FormIndex
I think that the problem is in the way LyX calls "update" function. For example, when I press "Undo" in the menu, the "Redo" command is still disabled. I have to move and click mouse in LyX working area to get it enabled. I would predict, that the toolbar should have the similar behavior. Undo/Redo problem disappeared when I called update() after executing LyX action in "void Menubar::Pimpl::callback(int action)". However, I don't think that this is the right place to do so. Marko
RE: Gnome: FormToc FormIndex
I'll move the callbacks to FormXxx (actually, FormPrint is the only one that needs it). Good than we can remove the unneeded files! Generally, glade produces this file for every project. However, as far as I have seen it is almost identical each time. You can desire not to produce this file, but Glade assumes that you have one in the code it produces. And there is at least one function which is really required by my implementation: lookup_widget. If it's always identical we could just modify it and leave it there as a class helper function. I think that the problem is in the way LyX calls "update" function. For example, when I press "Undo" in the menu, the "Redo" command is still disabled. I have to move and click mouse in LyX working area to get it enabled. I would predict, that the toolbar should have the similar behavior. Well I tracked this down till LyXView::showState which updates the right things and the toolbar than is updated. If showState is not called there is no update at all! IMO there has some logic to be changed, but I've no clue where to start looking at this, maybe we should just wait for Jean-Marcs return and hear what wise things he has to tell us :) Then now I get some gtk errors when I'm inside a tabular like this: Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Could you have a look at them? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Hire the morally handicapped.
RE: Gnome: FormToc FormIndex
If it's always identical we could just modify it and leave it there as a class helper function. true Well I tracked this down till LyXView::showState which updates the right things and the toolbar than is updated. If showState is not called there is no update at all! IMO there has some logic to be changed, but I've no clue where to start looking at this, maybe we should just wait for Jean-Marcs return and hear what wise things he has to tell us :) I suppose that we need to call update after each action is executed regardless of the source of the action (menu, toolbar, pipe). Then now I get some gtk errors when I'm inside a tabular like this: Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Could you have a look at them? Well, I can't reproduce it (or I don't undestand how I can get into this "tabular" thing :) ). However, if you know any LyX action which changes its state after you enter tabular from "plain action" to action which can be toggled (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you should know the cause. Namely, when the menu is composed I use either regular or if the action is toggled on/off --- GtkCheckMenuItem. Do you know any means how can I know on beforehand whether the action is toggleable? Marko
RE: Gnome: FormToc FormIndex
Well, I can't reproduce it (or I don't undestand how I can get into this "tabular" thing :) ). However, if you know any LyX action which changes its state after you enter tabular from "plain action" to action which can be toggled (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you should know the cause. Namely, when the menu is composed I use either regular or if the action is toggled on/off --- GtkCheckMenuItem. Do you know any means how can I know on beforehand whether the action is toggleable? That's the problem and IMO therefore the xforms implementation remakes the menu on the fly when it is opened. The problem is that we have only 4 states Disabled, Enabled, On and Off. To know this before we would need 6 of them Disabled, Enabled, On, Off, OnDisabled and OffDisabled! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Behind every great man, there is a woman -- urging him on. -- Harry Mudd, "I, Mudd", stardate 4513.3
RE: Gnome: FormToc FormIndex
On Fri, 18 Aug 2000, Juergen Vigna wrote: Well, I can't reproduce it (or I don't undestand how I can get into this "tabular" thing :) ). However, if you know any LyX action which changes its state after you enter tabular from "plain action" to action which can be toggled (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you should know the cause. Namely, when the menu is composed I use either regular or if the action is toggled on/off --- GtkCheckMenuItem. Do you know any means how can I know on beforehand whether the action is toggleable? That's the problem and IMO therefore the xforms implementation remakes the menu on the fly when it is opened. The problem is that we have only 4 states Disabled, Enabled, On and Off. To know this before we would need 6 of them Disabled, Enabled, On, Off, OnDisabled and OffDisabled! Hmm. Can't we have LyXFunc::Disabled | LyXFunc::ToggleOn and LyXFunc::Disabled | LyXFunc::ToggleOff ? This means that it is the responsibility of the programmer that implements some new action to define its state this way (we can use LyXFunc::ToggleOff as the default for this kind of actions). Marko
RE: Gnome: FormToc FormIndex
On 18-Aug-2000 Marko Vendelin wrote: Hmm. Can't we have LyXFunc::Disabled | LyXFunc::ToggleOn and LyXFunc::Disabled | LyXFunc::ToggleOff ? This means that it is the responsibility of the programmer that implements some new action to define its state this way (we can use LyXFunc::ToggleOff as the default for this kind of actions). I guess you got me here I'll try to have a look at this :) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dammit Jim, I'm an actor, not a doctor.
Other ideas for porting to windows
Hi! (About the e-mail from Baruch Even) I think that one good idea for writing a port of lyx to win 32 would be using a GUI that can be used both on unix and Windows. One option would be gtk (but not gnome) Other option would be the Fast ligth toolkit (see http://www.fltk.org) which is a free (LGLP'ed) toolkit compatible with Xforms. I think that whith a little effort we may write an fltk frontend (I will try, but I'm not promising anything) This way we may also get rid of the propietary Xforms library ! Thank you Pablo De Napoli
[cpptips] a little initialization gem (fwd)
Just got this from the cpptips mailing list of Allan Clarke, this might be
usefull as an ass keeper for all those uninitialized pointers in our code.
What do you say about adding it to the src/support ?
(And about me disappearing for next week, well that will happen sunday).
--
Baruch Even
http://techst02.technion.ac.il/~sbaruch/ (My Site)
http://rpghost.com/jindor/ (My brothers ADD site)
" Learn to laugh ... it's the path to true love! "
- The Angel in the movie Michael
-- Forwarded message --
Date: Fri, 18 Aug 2000 11:05:31 -0500
From: Allan Clarke [EMAIL PROTECTED]
To: cpptips [EMAIL PROTECTED]
Subject: [cpptips] a little initialization gem
TITLE: a little initialization gem
(Newsgroup: comp.lang.c++.moderated, 21 May 2000)
GARDNER: Howard Gardner [EMAIL PROTECTED]
// Mostly when I post here, I'm asking questions.
// And mostly I get good answers. So, by way
// of saying thanks, here's a simple little class
// that virtually eliminates "uninitialized variable"
// bugs. It has saved me untold time over the last
// few years, yet I haven't run across it anywhere.
template class T, T default_value=0 class auto_init
{
public:
typedef T value_type;
private:
value_type value;
public:
// This is the point of the exercise: provide a default constructor
auto_init(void)
:value(default_value)
{}
// These make it close to interchangeable with T
auto_init(const auto_init other)
:value(other.value)
{}
explicit auto_init(value_type initial_value)
:value(initial_value)
{}
auto_init operator = (const auto_init other)
{ value = other.value; return *this; }
auto_init operator = (value_type new_value)
{ value = new_value; return *this; }
operator value_type (void)
{ return value; }
// And these are useful sometimes
value_type get(void) const
{ return value; }
void set(value_type new_value)
{ value = new_value; }
};
// You can do this for all the builtin types...
typedef auto_initint int_auto_init;
#include iostream
void main(void)
{
using namespace std;
// Most of the time, I can't tell the difference from the init'd type:
int_auto_init a;
int_auto_init b;
a = 6;
b = a;
int_auto_init c (a*b + 100);
int z = c - 29 + a;
cout "a = " a endl;
cout "b = " b endl;
cout "c = " c endl;
cout "z = " z endl;
// But sometimes I can:
int_auto_init x;
// cin x;
int_auto_init::value_type temp_x;
cin temp_x;
x.set(temp_x);
cout x endl;
}
// It also saves having to write many default constructors,
// which eliminates both the code and the bugs it would have
// contained.
class without_auto_init
{
int a;
int b;
int c;
public:
without_auto_init(void)
:a(0), b(0), c(0)
{}
};
class with_auto_init
{
int_auto_init a;
int_auto_init b;
int_auto_init c;
};
// I've actually experimented with many variations on this theme:
// passing references (rather than values) in and out of the
// functions, and building in a conversion so you can effectively
// replace T's default constructor are a couple useful ones, but
// this rendition can save you incredible amounts of time. I'd love
// to find a way to make auto_initT completely interchangeble with T.
// And, of course, I'd love to see any little gems the rest of you are
// holding onto.
BARFURTH: Barfurth [EMAIL PROTECTED], 26 May 2000
This is most useful for declaring members of classes with multiple
constructors (assuming most of these initialize the element to the
same value).
When you add/remove members or add/remove constructor overloads you
can be sure the member will be initialized to a value that is
meaningful (or at least has a predictable wrong value :o). Without
such a class you have to manually keep in sync multiple initializer
lists.
HUBER: Heinz Huber
Wouldn't it be possible to overload operator for auto_init:
template class T istream operator (istream is, auto_initT ai)
{
T temp;
is temp;
ai = temp;
return is;
}
[snip]
GARDNER: 26 May 2000
Yes, that works for the extractor. Many similar cases will pop up,
though: that line was meant to represent all of the annoying places
where C++ isn't able to apply the cast automatically. It was meant
as fair warning that this class is not an exact substitution for the
init'd type, and it will irritate you at times.
___
cpptips mailing list
http://cpptips.hyperformix.com
BUG when closing document
Whoever did the new FormDocument, I BLAME YOU! I've been chasing the last hour or two (after being up all night) chasing a bug that was supposedly in my code, after chasing it off with the unkind help of ddd/gdb I found the culprit to be (supposedly, havent verified it completely) in the function CloseAllBufferRelatedDialogs(), I KNOW that the problem is in this function, what I believe is that the problem is caused by an access to an uninitialized variable, fd_form_document and its relatives there are a good chance. This is not my code and I'm sleepy by now, so I'll leave it to whomever touched one of those dialogs and didn't finish it in that function. May I say that hunting for a bug caused by a function call that goes through signals is a real nightmare (luckily I'm going to sleep during the day :-), It's been a hectic hunting to find the called function. But maybe it's because I hardly know ddd/gdb debugging methods. For such things a debugging code in the signalling methods could be usefull, to print the called functions before calling them. Will simplify finding where the trouble really occured. I'm off to sleep, good night/day/whatever. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers ADD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: BUG when closing document
On Sat, 19 Aug 2000, Baruch Even wrote: Whoever did the new FormDocument, I BLAME YOU! Sorry for this harsh language, I'm too tired to think anymore. I apologize if (and even if not) someone got hurt by this. Wouldn't happen again in the next 8 hours. I Promise! :-) (I also claim that I'm still continuing the friday since I haven't gone to sleep since friday morning). -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers ADD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: GUII pixmaps
On Fri, 18 Aug 2000, Dekel Tsur wrote: > Imagemagick also support transformation (e.g. convert -rotate 30), > and it can convert from eps to any format (using gs). > It also include a shared library (libmagick). > I'm not sure how useful it is for your purposes, but I'll leave it to you to > do the research :) I know about ImageMagick, I intend to support it, but I think it is better to use ghostscript which every LyX user currently have already, I'll add ImageMagick has a second backup, possibly a better solution than gs, but first I want to have backward compatiblity with former lyx versions. > PS: I still think that you should try making the image viewing be done > without creating temporary XPM (or other) files (after the image is converted > to a format readable by (pdf)latex, i.e. eps/pdf/png/jpeg). I wouldn't mind doing such a thing, however I cannot figure how to do it. If you have any idea I'd like to hear about it. Note that Lars(?) asked me to avoid using the ghostscript x11 driver so the way it is done currently is unwanted. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers AD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: GUII pixmaps
On Thu, 17 Aug 2000, Garst R. Reese wrote: > Dekel Tsur wrote: > > > > On Thu, Aug 17, 2000 at 09:44:48AM +0300, Baruch Even wrote: > > > On 17 Aug 2000, Miyata Shigeru wrote: > > > > > > > Lastly for linear transform of a graphic buffer of X, we may adopt libart > > > > http://www.levien.com/libart/ > > > > > > I'll check it out too, however I was told to avoid adding dependencies, so > > > I'll have to support ghostscript as a transformer and libxpm as a loader > > > to make sure that everything will continue to work, even though I think it > > > will still require an added dependency on ImageMagick or something else to > > > transfer between png and xpm. > > > > Imagemagick also support transformation (e.g. convert -rotate 30), > > and it can convert from eps to any format (using gs). > > It also include a shared library (libmagick). > > I'm not sure how useful it is for your purposes, but I'll leave it to you to > > do the research :) > > > > PS: I still think that you should try making the image viewing be done > > without creating temporary XPM (or other) files (after the image is converted > > to a format readable by (pdf)latex, i.e. eps/pdf/png/jpeg). > > It might be useful to poll the dev and user lists to determine what they > already have installed. Other things else I have require Imagemagick, > imlib,libpng, and libart, so it is hard to imagine that anything that > lyx wants is going to be a problem. The gnome stuff is so incredibly > heavy that I think worrrying about this issue is futile. Especially > after teTeX and ghostscript. > Garst > I don't think that this things will be a problem to add, but if I can avoid ADDING DEPENDENCIES I'd rather do that. Thus I'll support initially the ghostscript method, hopefully without the need for ImageMagic. And then I can add additional methods that will complement and improve on the basic, this way I'll be assured that former users can continue to use LyX without new installations, and that everyone will be able to benefit from the additional features if the only install (or already have) some additional dependencies. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers AD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: Suggestion on FormTabular: Cell cettings and multicol
On Thu, 17 Aug 2000, Baruch Even wrote: > On 17 Aug 2000, Lars Gullik Bjønnes wrote: > > > Baruch Even <[EMAIL PROTECTED]> writes: > > > > | It might be a good idea to release soon a lyx-1.1.6-beta1 in order to do > > | the testing by those who will need to use the code. It would be a bad idea > > | to release so much new code without having some brave users test it > > | beforehand, > > > > We always have at lest three prereleases if tere have been a lot of > > changes, so the questions if we should push forward and go direcly > > for the 1.2.0 goal, or stop up a bit and release 1.1.6pre1 (and we > > have work that is needed for that too...), if we don't release a > > 1.1.6pre we enable the NEW_TABULAR and NEW_INSETS wait a bit, fix > > stuff implement some, and release a 1.2.0pre1 My vote: 1.1.6 then 1.2.0 We have gone long enough without a prerelease. If we switch to the comparatively untested NEW_[EVERYTHING] stuff¹ we are likely to slow down development excessively I feel. At least with the mostly old stuff in place we know a lot of it is "stable". Then 1.1.6 can be completed and we can do a proper job of 1.2.0. Fixing all the other intermediate problems as we go. So we end up doing all the same work but at least get more people using at least one of the releases (1.1.6). ¹ Lars issued a challenge, I published it in LDN and almost none responded. > I think that taking a break now will be a good idea, we could then try to > aim for better support for GUII in 1.2.0, as far as I looked into it, it > will require quite a bit of work to get LyX fully GUII, quite a bit of its > internals are dependent on X windows calls. There's GUII and SI (System Independence). X is used on all the Unix platforms and keeps us going on Windows and OS/2. Lets get the GUI independent of toolkits first (but still dependent on X) and then get independent of X. That doesn't mean we should ignore SI issues just that we concentrate on sweeping the floor [removing xforms/toolkit code from the core] before we polish it [make it shine ;-)]. For 1.2.0 I'd be happy to have most of the dialogs in all three toolkit ports. We don't need all of them but it would certainly make a nice milestone for 1.2.0 to be toolkit agnostic. Then 1.x.0 (x >=3; probably x>>3) can be the SI or XI target. These thoughts are also due to the number of people who will still be thinking in Linux-kernel numbering instead of just-another-release numbering. [imlib dependency] I'd rather do without inline rendering until later and have you work on all those other things you listed. Allan. (ARRae)
Re: Suggestion on FormTabular: Cell cettings and multicol
On 17-Aug-2000 Lars Gullik Bjønnes wrote: > > NEW_INSETS should be enabled at the same time, because: > - keep the fileformat changes localized to on version > - they also use the textinsets and the other insets that > tabular uses, better testing. > - deveopment for 1.3.0 will be a lot cleaner since we can > remove a lot of cruft intermixing table/flotat code. > - why should you get your code in and I not mine? > Well to answer you what I think: - the fileformat will change and change again between version, as we will change stuff and add new features, so this is bogus. - better testing I agree completely - well as we will have a 1.1.6 then 1.2.0 development until 1.3.0 will pass quite some time - and to this I only have to say that probably I won't include more of mine work then of your work! InsetCollapsable is the base for all other text-based insets we made till now which are really only derived insets! Why activate NEW_TABULAR and not NEW_INSETS: - new tabular is mainly finished, there are some problems (mainly with mouse selection) and maybe some behaviours user don't like so much, but I regard it a feature complete! This is the only table code I will support from now on, there is lot's of stuff User asked for in a long time and we could give the user a first impression of the new stuff we will make available in the next version after 1.1.6 (1.2.0). - We have still quite a lot of problems to resolve with other insets, especially your baby the minipage inset is just there to be there it's the same as a foot inset without more support and there is a lot of work to do to make this work so we would have to stale the release of a 1.1.6pre1 just to make all the changes necessary to implement minipages in clean way. - Not only that but we also have to resolve the problems in reading all the right stuff from dummy paragraphs into the right text-inset, which is IMO also quite a bit of work. So you see while the tabular-inset IS ready for prime-time most (it reads all old code correct I tried this with various files and also the UserGuide!) the other text inset still need lot's of work. > If we decide for 1.2.0 I will enable NEW_TABULAR and NEW_INSETS right > away. And then you will get some testing. Also at once when we have > the remaining bits in place we will release 1.2.0pre1 and you will > probably get even more testing then. No I think we should release a 1.1.6 before, we can have a vote if and what we want to activate if all core developer (Note: this is a decission ONLY now working developers can take, this includes all of you sending regular patches and who took up a part of the sourcetree for their responsability!). My vote is 1.1.6 with ONLY NEW_TABULAR activated! > > It does not seem to be quite equivalent with the old code, at least > some warnings are missing wen you switch document classes. It also > seems to me that the new document defaults are not set. Yes I've seen that warnings are not put out and I investigate that, but the documents defaults ARE set I tried that, well I will put #ifdef stuff around the old code so we'll see what will fall away and if it works when it is not anymore there. Jürgen P.S.: You still didn't say if you like the new layout or if you would like it some other way ;) -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Duct tape is like the force. It has a light side, and a dark side, and it holds the universe together ... -- Carl Zwanzig
Re: The external inset once again (was: user-feedback on 116cvs)
On 17-Aug-2000 Asger K. Alstrup Nielsen wrote: > Juergen has demonstrated this nicely with his excellent work on the > new tabular inset. > > Btw, I hope people appreciate the excellent work Juergen and Lars are > doing with the text insets. Their work is very much related to > infrastructure, and therefore not as immediately visible as much of the > other excellent work being done on the GUII, i18n, and more. > I'm not trying to tone down the importance of this other work, but I'd > just like to publically pad these guys on their back and say: Good work, > have a beer! And while we are at it, you other guys can have one as well. > Well I have to admit to hear this from you feels good #:O) And I had a beer yesterday on this! #:O) Jürgen P.S.: And it was a lot of work, after the FILM I worked more or less 4-5 hours a day on lyx to complete all the work we stared there. -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Non-sequiturs make me eat lampshades.
Re: Changing tabular multirow latex output!
On 17-Aug-2000 Bernd Paysan wrote: > I'm using latext CVS (i.e. the bug report is related to insettabular.C > rev. 1.44, Aug 11). I'll give a more detailed bug report in the following > lines: > For now thanks for the report I will replay to the single points when I find the time to have a look, but you're report will surely help to make tabular-insetes even better! Greets Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The Phone Booth Rule: A lone dime always gets the number nearly right.
Re: Suggestion on FormTabular: Cell cettings and multicol
On Fri, 18 Aug 2000, Allan Rae wrote: > > I think that taking a break now will be a good idea, we could then try to > > aim for better support for GUII in 1.2.0, as far as I looked into it, it > > will require quite a bit of work to get LyX fully GUII, quite a bit of its > > internals are dependent on X windows calls. > > There's GUII and SI (System Independence). X is used on all the Unix > platforms and keeps us going on Windows and OS/2. Lets get the GUI > independent of toolkits first (but still dependent on X) and then get > independent of X. That doesn't mean we should ignore SI issues just that > we concentrate on sweeping the floor [removing xforms/toolkit code > from the core] before we polish it [make it shine ;-)]. I thought GUII to include SI, and think that we should go at the 1.2.0 level on a sweeping work to move everything X or Toolkit dependent to other classes. The work itself to create a Windows/OS2/Mac/BeOS/Commodore64 version of LyX probably wouldn't be done so fast anyhow. But the localization of everything frontend related in the frontends directory/domain is a very good idea IMHO. > For 1.2.0 I'd be happy to have most of the dialogs in all three toolkit > ports. We don't need all of them but it would certainly make a nice > milestone for 1.2.0 to be toolkit agnostic. Then 1.x.0 (x >=3; probably > x>>3) can be the SI or XI target. In any way that you look at it, in order to be really toolkit agnostic you'll need to seperate the frontend from the core. Otherwise you'll have trouble LyX work completely in a single toolkit, as opposed to now that the Gnome/KDE ports are part Native part XForms, I know the problem of porting all dialogs to the toolkit, it takes time, but the main app itself is not portable, even though there is a move toward it with the toolbars and the mainmenu. > [imlib dependency] > > I'd rather do without inline rendering until later and have you work on > all those other things you listed. I actually consider the inline rendering a must before going to the wild word of creeping freaturism. Inline rendering is expected anywhere a graphics is embedded, it will be important also to the External/Graphics Inset combination, and is as far as I can see it the main reason why I wouldn't suggest replacing the FigInset with the GraphicsInset at this time. Adding features to the GI will not be too hard a task, many things that can be added are pretty simple to do, some others are more elaborate, but I do think that none of them is in the order of the inline rendering. Besides the inline rendering as it is developed now will give me the tool for a freeping creature, Having thumbnails in the image file chooser, that will be a neat feature (freeping creaturism or not?! :-) -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers AD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
LyXImage patch
Attached again is the LyXImage patch, there were some updates to the tree and it is (for) now against the latest CVS. I won't be here till at least tuesday and possibly all of next week, if you find any trouble with the patch don't apply it as I won't be able to have a good response, I'll try to stay connected and working during this time but as I said, the machine there is not suitable for development. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers AD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael patch.gz
insettabular: double lines
While testing the new tabular inset, I realized that in some cases LaTeX will make a double line where the tabular inset only displays a single. To reproduce this, one has to mark two cells which lie side by side both multicol, then assign a right border line to the left one and a left border line to the right one. Timm
Re: [PATCH] KDE FormUrl
On Thu, 17 Aug 2000, Allan Rae wrote: > > 1) As I pointed out, layout isn't handled by kdlgedit. So this > >doesn't use it. Is this OK ? > > Is this the geometry stuff you were referring to for the copyright dialog? > Yes. I actually had a mail over the weekend from someone who implied Qt Designer can generate Qt 1.1 only code, which wasn't at all clear from the tarball of Qt 2.2.beta. If this is true, then we can switch to using that, and everyone is happy :) > [2&3 will have to wait till I have time to read the code and figure out > what you are talking about...] > > > 4) I wasn't sure about using ButtonPolicies as i've not examined that code > >yet (STL still looks like line noise to me i'm afraid :() > > With a vector implementation it should look like a two dimensional array. > You have to write your own version of ButtonController that works with > Qt/KDE buttons in the same manner that xforms/ButtonController.h does. > The STL code used is pretty simple. So just look at what ButtonController > does and don't worry about the implementation of ButtonPolicies. Just > worry about which button policy is appropriate for a given dialog. > > Also don't feel that you _have_ to use the existing policies. If KDE has > different ideas about what an applicxation should do with its buttons then > maybe implement > OK, that's good. I think it might be useful anyway, I'll look at this. > > Or better yet try using a status variable as defined in > DialogBase.h. Even better would be to use the appropriate policy from > button policy. I'm thinking about adding a "list read_only;" > to ButtonController so that we can push all the widgets we want disabled > on a read-only status (or some other status as defined by the policy) into > the list and then not have to worry about handling de/activation > separately. > > Allan. (ARRae) > yes, a button policy seems to be the way to go on this. Note in kde/ I hide the "OK" button, and make Cancel "Close". This seems a more sensible presentation to the user ... thanks Allan ! john -- "The path you specified contains too many directories. Delete one or more directories or clear the Include Subdirectories checkbox." - Microsoft Office
RE: Gnome: FormToc & FormIndex
> > not all are empty (diaprint_callbacks.c). Well, the rest are empty, that's > true. In general, more complex dialogs will require some callbacks. I > think that if we will remove these (empty) files then we will have to > postprocess Glade-generated _interface files which include _callbacks. > I guess the callbacks should go into the FormXxx files and so we can remove this additional files and yes we have to postprocess the .[ch] files I've seen that already, so if you move the callbacks you use into the FormXxx implementation I see then to get rid of the #includes in the interface files and we should make a Makefile in the dialogs-directory which can produce the right files and postprocess them automatically (if I'm not mistaken glade has some sort of export option at least I've seen this in the archimedes project) > >> - would it be possible to postprocess the .[ch] files so that we can get >> .[Ch] files as we do with fdesign generated files? (I would help to >> implement this if you like it!) > > In all computers that I've seen, gcc compiles files faster than g++. Do we > need to have compilation times longer? :) > Well I let Allan or others explain why they would like .C files instead of .c files I'm not the expert here #:O) >> - what is this support.[ch] is it always generated by glade? > > yes. at least one function is used by me directly: lookup_widget. > Yes but is this generated for each .glade file you process or do you have to call glade with some special option to process it? And does glade use this then or you have to use the functions for your implementation? > > This is much better implementation. Should I change it or you will make > it? Well it's your baby :) > >> - I will also have a look why some menu-items are never enabled and/or >> displayed wrong. > > Is it Gnome-specific or the same trouble is with XForms implementation? This is Gnome-specific, I had a look and there is some problem with the update of the menus. While in the xforms part the menu is rebuild when I press on a menu-button this does not happen in gnome. I will have a better look but you should try too as you know better than me how gnome-menus work ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ We don't believe in rheumatism and true love until after the first attack. -- Marie Ebner von Eschenbach
Re: [PATCH] KDE FormUrl
On Fri, 18 Aug 2000, John Levon wrote: > Yes. I actually had a mail over the weekend from someone who implied Qt > Designer can generate Qt 1.1 only code, which wasn't at all clear from the > tarball of Qt 2.2.beta. If this is true, then we can switch to using that, > and everyone is happy :) > apologies for the post to self, but I got a reply from the guy and it seems I misunderstood him. The kdevelop branch can be used for both versions, but not Qt Designer. So it seems there isn't an available dialog editor :( Juergen, I tried *very* hard to use Qt Architect 1.4.4 to design FormIndex. It kept on breaking when I used layouts, making one of the buttons disappear, with no way of getting it back (except by editing the generated file, but that kind of defeats the point :). thanks john -- "The path you specified contains too many directories. Delete one or more directories or clear the Include Subdirectories checkbox." - Microsoft Office
Re: [PATCH] KDE FormUrl
> > apologies for the post to self, but I got a reply from the guy and it > seems I misunderstood him. The kdevelop branch can be used for both > versions, but not Qt Designer. So it seems there isn't an available dialog > editor :( > Well you tried ;) > Juergen, I tried *very* hard to use Qt Architect 1.4.4 to design > FormIndex. It kept on breaking when I used layouts, making one of the > buttons disappear, with no way of getting it back (except by editing the > generated file, but that kind of defeats the point :). Depends on what you had to change and how much work it was to change it! We could use 2 methods: 1. a general sed script (prefered) 2. a patch (as with some dialogs in the xforms tree) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ When in panic, fear and doubt, Drink in barrels, eat, and shout.
RE: Gnome: FormToc & FormIndex
On Fri, 18 Aug 2000, Juergen Vigna wrote: > I guess the callbacks should go into the FormXxx files and so we can > remove this additional files and yes we have to postprocess the .[ch] > files I've seen that already, so if you move the callbacks you use into > the FormXxx implementation I see then to get rid of the #includes in > the interface files and we should make a Makefile in the dialogs-directory > which can produce the right files and postprocess them automatically > (if I'm not mistaken glade has some sort of export option at least I've > seen this in the archimedes project) I'll move the callbacks to FormXxx (actually, FormPrint is the only one that needs it). > > In all computers that I've seen, gcc compiles files faster than g++. Do we > > need to have compilation times longer? :) > > Well I let Allan or others explain why they would like .C files instead of > .c files I'm not the expert here #:O) I'm eager to hear it. Or is it FAQ-type question and I should look into developers-FAQ? > >> - what is this support.[ch] is it always generated by glade? > > > > yes. at least one function is used by me directly: lookup_widget. > > > > Yes but is this generated for each .glade file you process or do you have > to call glade with some special option to process it? And does glade use > this then or you have to use the functions for your implementation? Generally, glade produces this file for every project. However, as far as I have seen it is almost identical each time. You can desire not to produce this file, but Glade assumes that you have one in the code it produces. And there is at least one function which is really required by my implementation: lookup_widget. > > This is much better implementation. Should I change it or you will make > > it? > > Well it's your baby :) I'll patch it. > This is Gnome-specific, I had a look and there is some problem with the > update of the menus. While in the xforms part the menu is rebuild when > I press on a menu-button this does not happen in gnome. I will have a better > look but you should try too as you know better than me how gnome-menus > work ;) I think that the problem is in the way LyX calls "update" function. For example, when I press "Undo" in the menu, the "Redo" command is still disabled. I have to move and click mouse in LyX working area to get it enabled. I would predict, that the toolbar should have the similar behavior. Marko
RE: Gnome: FormToc & FormIndex
> I think that the problem is in the way LyX calls "update" function. For > example, when I press "Undo" in the menu, the "Redo" command is still > disabled. I have to move and click mouse in LyX working area to get it > enabled. I would predict, that the toolbar should have the similar > behavior. Undo/Redo problem disappeared when I called update() after executing LyX action in "void Menubar::Pimpl::callback(int action)". However, I don't think that this is the right place to do so. Marko
RE: Gnome: FormToc & FormIndex
> > I'll move the callbacks to FormXxx (actually, FormPrint is the only one > that needs it). > Good than we can remove the unneeded files! > > Generally, glade produces this file for every project. However, as far as > I have seen it is almost identical each time. You can desire not to > produce this file, but Glade assumes that you have one in the code it > produces. And there is at least one function which is really required by > my implementation: lookup_widget. > If it's always identical we could just modify it and leave it there as a class helper function. > > I think that the problem is in the way LyX calls "update" function. For > example, when I press "Undo" in the menu, the "Redo" command is still > disabled. I have to move and click mouse in LyX working area to get it > enabled. I would predict, that the toolbar should have the similar > behavior. Well I tracked this down till LyXView::showState which updates the right things and the toolbar than is updated. If showState is not called there is no update at all! IMO there has some logic to be changed, but I've no clue where to start looking at this, maybe we should just wait for Jean-Marcs return and hear what wise things he has to tell us :) Then now I get some gtk errors when I'm inside a tabular like this: Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Could you have a look at them? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Hire the morally handicapped.
RE: Gnome: FormToc & FormIndex
> If it's always identical we could just modify it and leave it there as a > class helper function. true > Well I tracked this down till LyXView::showState which updates the right > things and the toolbar than is updated. If showState is not called there > is no update at all! IMO there has some logic to be changed, but I've no > clue where to start looking at this, maybe we should just wait for Jean-Marcs > return and hear what wise things he has to tell us :) I suppose that we need to call update after each action is executed regardless of the source of the action (menu, toolbar, pipe). > Then now I get some gtk errors when I'm inside a tabular like this: > > Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' > > Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): > assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. > > Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' > > Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): > assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. > > Could you have a look at them? Well, I can't reproduce it (or I don't undestand how I can get into this "tabular" thing :) ). However, if you know any LyX action which changes its state after you enter tabular from "plain action" to action which can be toggled (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you should know the cause. Namely, when the menu is composed I use either regular or if the action is toggled on/off --- GtkCheckMenuItem. Do you know any means how can I know on beforehand whether the action is toggleable? Marko
RE: Gnome: FormToc & FormIndex
> > Well, I can't reproduce it (or I don't undestand how I can get into this > "tabular" thing :) ). However, if you know any LyX action which changes > its state after you enter tabular from "plain action" to action which can > be toggled (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you should know > the cause. Namely, when the menu is composed I use either regular or if > the action is toggled on/off --- GtkCheckMenuItem. Do you know any means > how can I know on beforehand whether the action is toggleable? That's the problem and IMO therefore the xforms implementation remakes the menu on the fly when it is opened. The problem is that we have only 4 states Disabled, Enabled, On and Off. To know this before we would need 6 of them Disabled, Enabled, On, Off, OnDisabled and OffDisabled! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Behind every great man, there is a woman -- urging him on. -- Harry Mudd, "I, Mudd", stardate 4513.3
RE: Gnome: FormToc & FormIndex
On Fri, 18 Aug 2000, Juergen Vigna wrote: > > > > Well, I can't reproduce it (or I don't undestand how I can get into this > > "tabular" thing :) ). However, if you know any LyX action which changes > > its state after you enter tabular from "plain action" to action which can > > be toggled (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you should know > > the cause. Namely, when the menu is composed I use either regular or if > > the action is toggled on/off --- GtkCheckMenuItem. Do you know any means > > how can I know on beforehand whether the action is toggleable? > > That's the problem and IMO therefore the xforms implementation remakes the > menu on the fly when it is opened. The problem is that we have only 4 states > Disabled, Enabled, On and Off. To know this before we would need 6 of them > Disabled, Enabled, On, Off, OnDisabled and OffDisabled! Hmm. Can't we have LyXFunc::Disabled | LyXFunc::ToggleOn and LyXFunc::Disabled | LyXFunc::ToggleOff ? This means that it is the responsibility of the programmer that implements some new action to define its state this way (we can use LyXFunc::ToggleOff as the default for this kind of actions). Marko
RE: Gnome: FormToc & FormIndex
On 18-Aug-2000 Marko Vendelin wrote: > > Hmm. Can't we have LyXFunc::Disabled | LyXFunc::ToggleOn and > LyXFunc::Disabled | LyXFunc::ToggleOff ? This means that it is the > responsibility of the programmer that implements some new action to define > its state this way (we can use LyXFunc::ToggleOff as the default for > this kind of actions). I guess you got me here I'll try to have a look at this :) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dammit Jim, I'm an actor, not a doctor.
Other ideas for porting to windows
Hi! (About the e-mail from Baruch Even) I think that one good idea for writing a port of lyx to win 32 would be using a GUI that can be used both on unix and Windows. One option would be gtk (but not gnome) Other option would be the Fast ligth toolkit (see http://www.fltk.org) which is a free (LGLP'ed) toolkit compatible with Xforms. I think that whith a little effort we may write an fltk frontend (I will try, but I'm not promising anything) This way we may also get rid of the propietary Xforms library ! Thank you Pablo De Napoli
[cpptips] a little initialization gem (fwd)
Just got this from the cpptips mailing list of Allan Clarke, this might be
usefull as an ass keeper for all those uninitialized pointers in our code.
What do you say about adding it to the src/support ?
(And about me disappearing for next week, well that will happen sunday).
--
Baruch Even
http://techst02.technion.ac.il/~sbaruch/ (My Site)
http://rpghost.com/jindor/ (My brothers AD site)
" Learn to laugh ... it's the path to true love! "
- The Angel in the movie Michael
-- Forwarded message --
Date: Fri, 18 Aug 2000 11:05:31 -0500
From: Allan Clarke <[EMAIL PROTECTED]>
To: cpptips <[EMAIL PROTECTED]>
Subject: [cpptips] a little initialization gem
TITLE: a little initialization gem
(Newsgroup: comp.lang.c++.moderated, 21 May 2000)
GARDNER: Howard Gardner <[EMAIL PROTECTED]>
// Mostly when I post here, I'm asking questions.
// And mostly I get good answers. So, by way
// of saying thanks, here's a simple little class
// that virtually eliminates "uninitialized variable"
// bugs. It has saved me untold time over the last
// few years, yet I haven't run across it anywhere.
template class auto_init
{
public:
typedef T value_type;
private:
value_type value;
public:
// This is the point of the exercise: provide a default constructor
auto_init(void)
:value(default_value)
{}
// These make it close to interchangeable with T
auto_init(const auto_init & other)
:value(other.value)
{}
explicit auto_init(value_type initial_value)
:value(initial_value)
{}
auto_init & operator = (const auto_init & other)
{ value = other.value; return *this; }
auto_init & operator = (value_type new_value)
{ value = new_value; return *this; }
operator value_type (void)
{ return value; }
// And these are useful sometimes
value_type get(void) const
{ return value; }
void set(value_type new_value)
{ value = new_value; }
};
// You can do this for all the builtin types...
typedef auto_init int_auto_init;
#include
void main(void)
{
using namespace std;
// Most of the time, I can't tell the difference from the init'd type:
int_auto_init a;
int_auto_init b;
a = 6;
b = a;
int_auto_init c (a*b + 100);
int z = c - 29 + a;
cout << "a = " << a << endl;
cout << "b = " << b << endl;
cout << "c = " << c << endl;
cout << "z = " << z << endl;
// But sometimes I can:
int_auto_init x;
// cin >> x;
int_auto_init::value_type temp_x;
cin >> temp_x;
x.set(temp_x);
cout << x << endl;
}
// It also saves having to write many default constructors,
// which eliminates both the code and the bugs it would have
// contained.
class without_auto_init
{
int a;
int b;
int c;
public:
without_auto_init(void)
:a(0), b(0), c(0)
{}
};
class with_auto_init
{
int_auto_init a;
int_auto_init b;
int_auto_init c;
};
// I've actually experimented with many variations on this theme:
// passing references (rather than values) in and out of the
// functions, and building in a conversion so you can effectively
// replace T's default constructor are a couple useful ones, but
// this rendition can save you incredible amounts of time. I'd love
// to find a way to make auto_init completely interchangeble with T.
// And, of course, I'd love to see any little gems the rest of you are
// holding onto.
BARFURTH: Barfurth <[EMAIL PROTECTED]>, 26 May 2000
This is most useful for declaring members of classes with multiple
constructors (assuming most of these initialize the element to the
same value).
When you add/remove members or add/remove constructor overloads you
can be sure the member will be initialized to a value that is
meaningful (or at least has a predictable wrong value :o). Without
such a class you have to manually keep in sync multiple initializer
lists.
HUBER: Heinz Huber
> Wouldn't it be possible to overload operator >> for auto_init:
>
> template istream& operator >> (istream , auto_init ai)
> {
>T temp;
>is >> temp;
>ai = temp;
>return is;
> }
[snip]
GARDNER: 26 May 2000
Yes, that works for the extractor. Many similar cases will pop up,
though: that line was meant to represent all of the annoying places
where C++ isn't able to apply the cast automatically. It was meant
as fair warning that this class is not an exact substitution for the
init'd type, and it will irritate you at times.
___
cpptips mailing list
http://cpptips.hyperformix.com
BUG when closing document
Whoever did the new FormDocument, I BLAME YOU! I've been chasing the last hour or two (after being up all night) chasing a bug that was supposedly in my code, after chasing it off with the unkind help of ddd/gdb I found the culprit to be (supposedly, havent verified it completely) in the function CloseAllBufferRelatedDialogs(), I KNOW that the problem is in this function, what I believe is that the problem is caused by an access to an uninitialized variable, fd_form_document and its relatives there are a good chance. This is not my code and I'm sleepy by now, so I'll leave it to whomever touched one of those dialogs and didn't finish it in that function. May I say that hunting for a bug caused by a function call that goes through signals is a real nightmare (luckily I'm going to sleep during the day :-), It's been a hectic hunting to find the called function. But maybe it's because I hardly know ddd/gdb debugging methods. For such things a debugging code in the signalling methods could be usefull, to print the called functions before calling them. Will simplify finding where the trouble really occured. I'm off to sleep, good night/day/whatever. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers AD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: BUG when closing document
On Sat, 19 Aug 2000, Baruch Even wrote: > Whoever did the new FormDocument, I BLAME YOU! Sorry for this harsh language, I'm too tired to think anymore. I apologize if (and even if not) someone got hurt by this. Wouldn't happen again in the next 8 hours. I Promise! :-) (I also claim that I'm still continuing the friday since I haven't gone to sleep since friday morning). -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers AD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
