GNOME Bugzilla – Bug 694212
Slide in the message area using a GdRevealer
Last modified: 2013-06-16 16:07:52 UTC
The following patches implements sliding in of the message area in the sourceview plugin using a GdRevealer. The main problem is that it requires a really recent gtk+ version, 3.7.10, since the GdRevealer depends on that. Personally I would love to be able to follow gnome development closely but I guess other people like to have the ability to build Anjuta without using jhbuild.
Created attachment 236834 [details] [review] Add libgd submodule
Created attachment 236835 [details] [review] sourceview: use GdRevealer for sliding in the message area
(In reply to comment #0) > Personally I would love to be > able to follow gnome development closely but I guess other people like > to have the ability to build Anjuta without using jhbuild. I really prefer to build Anjuta without using jhbuild. I think it's really useful allowing bug reporters to compile and check the master branch or a newcomers to provide a patch more easily. Now, I'm fine if the new features can be disabled automatically or manually with a configure option. I don't know what is the opinion of others though.
In general I like the idea but I agree with Sébastien that this should be conditionally built. Just out of curiosity: What is this libgd thing about? Will this eventually end up in gtk+?
Review of attachment 236834 [details] [review]: Thanks for your patch, I have committed it.
Review of attachment 236835 [details] [review]: Thanks for your patch, I have committed it.
I have committed your two patches using libgd but I have added another patch allowing to build without it. I think it is nice to follow GNOME development. But I think it's important to keep Anjuta as easy as possible to build.
(In reply to comment #7) > I have committed your two patches using libgd but I have added another patch > allowing to build without it. I think it is nice to follow GNOME development. > But I think it's important to keep Anjuta as easy as possible to build. Actually GdRevealer has since I created the patch been integrated into gtk+ https://git.gnome.org/browse/gtk+/commit/?id=443459b52ea66bb20f1cf191333a8369c49cfe57 So I think we should remove the use of libgd and just use GtkRevelaer if the gtk+ version is new enough, do you agree?
(In reply to comment #8) > Actually GdRevealer has since I created the patch been integrated into gtk+ > https://git.gnome.org/browse/gtk+/commit/?id=443459b52ea66bb20f1cf191333a8369c49cfe57 > So I think we should remove the use of libgd and just use GtkRevelaer if the > gtk+ version is new enough, do you agree? Yes, sure. Keeping on optional dependency on libgd was not completely obvious, it will be easier to support two versions of GTK+. Then libgd could be useful for other widgets but we could still resurrect this commit later.
(In reply to comment #8) > Actually GdRevealer has since I created the patch been integrated into gtk+ > https://git.gnome.org/browse/gtk+/commit/?id=443459b52ea66bb20f1cf191333a8369c49cfe57 > So I think we should remove the use of libgd and just use GtkRevelaer if the > gtk+ version is new enough, do you agree? Just for my own clarification, why do we need to have a copy of libgd in our source tree? I noticed that our autogen.sh clones a copy of libgd from GNOME git into our tree. Why are we going through this much trouble? Even if GdRevealer weren't a part of GTK+, why wouldn't we just depend on libgd? It's not unheard of to have Anjuta depend on development versions of libraries during a development cycle, and then depend on a stable version once we make our stable release.
(In reply to comment #10) > Just for my own clarification, why do we need to have a copy of libgd in our > source tree? It's the way libgd is designed. It is a library so unstable that you cannot rely on an API. You have to include it in your project. There are more explanation in the README in the libgd directory. I have added it to see if we can use it without too much troubles, not for the improved message area. I don't want to require the latest version of Gtk+ because it makes Anjuta more difficult to build for newcomers. Carl would like to follow the latest version of Gtk+ and I think it's interesting too so I have tried to support both cases. Anyway, as the revealer has been included in Gtk, we can remove it again. But perhaps we could find some more interesting feature in libgd later.
(In reply to comment #11) > It's the way libgd is designed. It is a library so unstable that you cannot > rely on an API. You have to include it in your project. There are more > explanation in the README in the libgd directory. I looked at the README, and there's one part of it that really scares the hell out of me as a maintainer: "However, the design being not frozen, and the code being not yet mattured enough and proven, it is not possible for the developpers to guarantee API and propose the addition to the respective projects (Gtk+, or GLib for example) right now. Sharing the code allows to experiment, discuss and test together before proposing it upstream." They basically admit here that this thing isn't really production ready. I don't really love the idea of having to maintain our own fork of this library just to get some stability out of it. There's quite a few potential problems here that I can forsee: 1. What version of their code are we really using? Some arbitrary revision? Git master? 2. Conceivably we could create our own branch of their code and stick to it. But, what happens when we want to update our copy, for example to get new features or bug fixes? It seems that we would risk breaking our code if we did this. 3. How does this play with distcheck? The README also says that libgd isn't designed to be distributed by itself. If that's the case, how can we ensure that this code won't break distcheck for us? > I have added it to see if we can use it without too much troubles, not for the > improved message area. I don't want to require the latest version of Gtk+ > because it makes Anjuta more difficult to build for newcomers. Carl would like > to follow the latest version of Gtk+ and I think it's interesting too so I have > tried to support both cases. I appreciate your concern for new developers, but I'm concerned that we might regret depending on libgd like this. And personally, I don't really think having animated message areas is really important enough to depend on either libgd or the latest development GTK+. If you're worried about that dependency, it might be better to table this patch until this version of GTK+ goes stable in a few months. If you want to experiment with libgd just to see how it works out, I'd prefer that it was on a separate branch.
(In reply to comment #12) > I looked at the README, and there's one part of it that really scares the hell > out of me as a maintainer: Yes, I have read it and I agree with you. But at least, it is clear :) > 1. What version of their code are we really using? Some arbitrary revision? > Git master? I think everybody is using the same version which is the one that I have committed. It is currently git master but it will not follow. Changing the revision used has to be done manually. > 2. Conceivably we could create our own branch of their code and stick to it. I think that's exactly what is done currently. > But, what happens when we want to update our copy, for example to get new > features or bug fixes? If we want new features or bug fixes, we have to update it if we want by going in the libgd directory and update it as any other git repository then we go back in anjuta and commit the change. Everybody getting Anjuta will get the new version after running git submodule update --init --recursive. > 3. How does this play with distcheck? The source code of libgd will be included in the distribution package, so it will increase its size but that's all. > The README also says that libgd isn't > designed to be distributed by itself. If that's the case, how can we ensure > that this code won't break distcheck for us? Our own version of libgd will be compiled in Anjuta as a static library, so libgd doesn't appear as a library for the system, everybody is using his own version. > And personally, I don't really think > having animated message areas is really important enough to depend on either > libgd or the latest development GTK+. Yes, I'm fascinated by the usefulness of this class but obviously other guys have a different idea and I don't think they are all wrong. > If you're worried about that dependency, > it might be better to table this patch until this version of GTK+ goes stable > in a few months. In fact, we can already optionally depend on a more recent version of Gtk+ and avoid the use of libgd. But it can be more troubles. > If you want to experiment with libgd just to see how it works out, I'd prefer > that it was on a separate branch. Sorry, I haven't though about using a branch for that or simply asked before doing this experiment. Anyway, I think you overestimate the troubles brought by this "library". Look at git submodule. I have just read a few line to reply to your mail and one more time, I'm impressed by git doing things that I haven't imagined Contrary to Gtk+, we use a particular version of libgd that it included in Anjuta, so it's not another dependency but as a bonus we can update it easily. Quite several program already use libgd: devhelp, gnome-contacts, gnome-boxes, totem, gnome-photos, gnome-documents... So, I would rather keep it but I agree that it's almost useless currently so if you prefer we can remove it. I don't think so but it's still possible that it gives you some troubles when doing a release.
(In reply to comment #13) > (In reply to comment #12) > > I looked at the README, and there's one part of it that really scares the hell > > out of me as a maintainer: > > Yes, I have read it and I agree with you. But at least, it is clear :) Yeah, it's pretty clear that this stuff isn't really mature enough to be trusted. You might have a different idea, but I don't think anjuta master is the place for experimental code like this. > > But, what happens when we want to update our copy, for example to get new > > features or bug fixes? > > If we want new features or bug fixes, we have to update it if we want by going > in the libgd directory and update it as any other git repository then we go > back in anjuta and commit the change. Everybody getting Anjuta will get the new > version after running git submodule update --init --recursive. I see that autogen.sh can do this for us, which is great. But I'm more concerned about dealing with the fallout from code changes. Have you or Carl-Anton thought about how often we would update our copy and how we would handle code breakages? I'm worried that a careless update here could cause problems with our code that I would end up having to fix, especially problems with distcheck. > > > > 3. How does this play with distcheck? > > The source code of libgd will be included in the distribution package, so it > will increase its size but that's all. Yeah, I see that. What I really mean is, how can we be sure that their makefiles won't cause distcheck errors that I'll have to hunt down when we make a release? I'm guessing that libgd devs probably aren't paying attention to these things because they don't make releases themselves. Because we have libgd in our source tree, we (or possibly me, depending on the situation) are responsible for it if something breaks. > > And personally, I don't really think > > having animated message areas is really important enough to depend on either > > libgd or the latest development GTK+. > > Yes, I'm fascinated by the usefulness of this class but obviously other guys > have a different idea and I don't think they are all wrong. Even so, this is an awful lot of crap to go through for something that's not all that useful. I'm not saying that nothing good can come of libgd, but it's way too immature for us to even think about using right now. We shouldn't be in the business of testing what looks like another module's pre-alpha code. > > If you want to experiment with libgd just to see how it works out, I'd prefer > > that it was on a separate branch. > > Sorry, I haven't though about using a branch for that or simply asked before > doing this experiment. Well, I'm not going to tell you that you can't play around with libgd, but like I said before, I think we might be inviting trouble by putting it into master. I think it really belongs in another branch, at least for now. From time to time we can revisit this and see how libgd progresses. Once it becomes a little more stable, I have no problem using it. Now just doesn't seem like the time. Anjuta is complicated enough as it is. More code isn't an asset--it's a liability that introduces more opportunities for bugs and build system problems. I don't know about you, but having to deal with code that I don't know well and isn't very well tested doesn't make me feel warm and fuzzy... > Anyway, I think you overestimate the troubles brought by this "library". Look > at git submodule. I have just read a few line to reply to your mail and one > more time, I'm impressed by git doing things that I haven't imagined Yeah, git can do some wonderful things once you figure it out. The git plugin isn't as complicated as it is because I want it to be that way, it's like that because git itself is complicated. ;-) > > Contrary to Gtk+, we use a particular version of libgd that it included in > Anjuta, so it's not another dependency but as a bonus we can update it easily. > Quite several program already use libgd: devhelp, gnome-contacts, gnome-boxes, > totem, gnome-photos, gnome-documents... > > So, I would rather keep it but I agree that it's almost useless currently so if > you prefer we can remove it. I don't think so but it's still possible that it > gives you some troubles when doing a release. I don't mind having it around, I just think that it could be a problem for all of us at some point. FWIW, anjuta master still passes distcheck, so it's not a problem right now. But there's still a possibility that it could be, even months or even years down the road, by which time we'll all probably have long forgotten about this particular discussion. What would happen if something broke a year from now? I can just imagine going crazy trying to hunt down build system problems or API breakages. I don't know if you've ever had to do that when making a release, but when I took over releases from Johannes distcheck was still occasionally problematic. I spent many hours hunting down some really obscure distcheck problems. It's stable now; I'd like to keep it that way. Not that I want to rain on anyone's parade, but could you please move this to another branch until things stabilize? Thanks.
(In reply to comment #14) > Have you or > Carl-Anton thought about how often we would update our copy and how we would > handle code breakages? We shouldn't update our copy unless we find a bug in libgd which is fixed in a later version that's the goal of libgd. I don't expect any code breakage, unless Gtk+ changes and break something in libgd but it's not different from other parts of Anjuta. > Yeah, I see that. What I really mean is, how can we be sure that their > makefiles won't cause distcheck errors that I'll have to hunt down when > we make a release? The point is that basically, we don't update libgd. So if there is no breakage now, I don't see why you will get a breakage when you make the release. > I'm guessing that libgd devs probably aren't paying attention to > these things because they don't make releases themselves. They are the same guys who maintains Gtk+, so I agree that they are not the best one. But I think it will be better than Gtk+ which is considered as a stable library but which changes its behavior from time to time, breaking our code. And here we cannot keep a copy of it, we are forced to change our code. Moreover, several other GNOME applications already use libgd and make release with it. > Even so, this is an awful lot of crap to go through for something that's not > all that useful. I'm not saying that nothing good can come of libgd, but it's > way too immature for us to even think about using right now. I think you miss the point that libgd will never be a mature library that's one of its design goal. If the API of this code is considered as mature, it will enter in Gtk+ like it has been done for GtkRevealer object. > I don't mind having it around, I just think that it could be a problem for all > of us at some point. I'm sure it will add problems but it's like any additional code. I see no real difference with other parts of Anjuta as I think the majority of the code has not been written by one of us. I don't think this code is more buggy, it is written by people working on Gtk+ itself. If it's not a library, it is because the API is not stable but we don't care because we use one particular version of libgd, it is not different from our own internal APIs. > but could you please move this to another branch until things stabilize? There is no use of moving this to a branch because libgd will never stabilize. Then this particular Revealer object is now available in Gtk+, we can keep Carl's patches and use the object in Gtk+. But I still don't want to depend on the latest version of Gtk+ (the current one 3.4 is fine for me), so we need some conditional code to enable this or not depending on the version of Gtk we are using. Do you agree with that? If I have not convinced you, I will remove libgd. I understand your points and as you are making the release, I think it's fair that you decide. I'm busy this week end, so I will not be able to do it. But I will remove it next week before the release 3.9.3 else you can do it yourself. Carl, if James agrees could you use GtkRevealer instead of GdRevealer?
(In reply to comment #15) > The point is that basically, we don't update libgd. So if there is no breakage > now, I don't see why you will get a breakage when you make the release. Right, but I don't buy into the idea that we'll never update our copy. Eventually, we'll hit a bug or want new features. Might not be tomorrow, or even next year, but at some point we'll probably want to update. It would be nice if we never had to, but we need to be prepared if and when we do. > Moreover, several other GNOME applications already use libgd and make release > with it. Yeah, but are they as big as we are? > I think you miss the point that libgd will never be a mature library that's one > of its design goal. If the API of this code is considered as mature, it will > enter in Gtk+ like it has been done for GtkRevealer object. Exactly the point I'm trying to make. I don't think we should even be messing with anything in libgd until it becomes stable enough to become part of a more tested and proven library like GTK+. Yes, occasionally GTK devs make what might look like hasty decisions, but more often than not we can be assured that APIs will be stable until a major release comes along. That usually only happens once a decade. > > I don't mind having it around, I just think that it could be a problem for all > > of us at some point. > > I'm sure it will add problems but it's like any additional code. I see no real > difference with other parts of Anjuta as I think the majority of the code has > not been written by one of us. I don't think this code is more buggy, it is > written by people working on Gtk+ itself. If it's not a library, it is because > the API is not stable but we don't care because we use one particular version > of libgd, it is not different from our own internal APIs. The difference is that we wrote our code with our requirements, for both features and stability, in mind. And we have full control over what goes into it and when. With libgd, we might be able to control when we update it, but all hell could break loose if we ever do update and aren't careful. It could be no big deal, or it could be a total mess, kind of like anjuta-extras was during the 3.0 cycle. Remember how almost everything in there broke and I had to get rid of almost all of it before I could start releasing it again? I'd rather that didn't happen to Anjuta itself. In short, the idea that we can never reliably update is a little scary to me. > Then this particular Revealer object is now available in Gtk+, we can keep > Carl's patches and use the object in Gtk+. But I still don't want to depend on > the latest version of Gtk+ (the current one 3.4 is fine for me), so we need > some conditional code to enable this or not depending on the version of Gtk we > are using. Do you agree with that? Actually I'd leave this particular decision up to you, as I already have GTK 3.7 on my system. Speaking only for myself, I don't have any issues with GtkRevealer, but I understand your aversion to having to update GTK on what seems like a constant basis. So if you're OK with having to update your GTK, let's just have Carl-Anton update his patch to use GtkRevealer and just leave it at that. Otherwise we can just put this on hold until we have a more pressing reason to change our GTK+ dependency. > If I have not convinced you, I will remove libgd. I understand your points and > as you are making the release, I think it's fair that you decide. I'm sorry, but the more I think about libgd the more it bugs me. I think, for now at least, there's way too much risk involved for pretty much no benefit. Having to go through all of this for nothing more than animated message areas in sourceview just isn't worth either absorbing libgd or depending on GTK+ 3.7. I realize that at some point libgd might have things that are of more use to us. I can't really predict what those things might be, but we should revisit this issue every so often. If we find something really useful in some future version of libgd, maybe one day the risks will be worth it. So, I'm not going to say that we can never use libgd, but now just isn't the time. > I'm busy this week end, so I will not be able to do it. But I will remove it > next week before the release 3.9.3 else you can do it yourself. As 3.9.3 releases on Monday, I want to revert these patches right away. @Carl-Anton: if you and Seb think that using GtkRevealer is a good idea, just go ahead and commit an updated version of that patch to master once I revert the libgd version.
I see that a new patch has been committed, using conditional compile-time checks in the source file. I really have to give Carl-Anton props for meeting everybody's requirements, though this technique isn't something that should be used often, so I don't want it to become a habit. Closing this bug for now...
Just my cents: * We have been using libegg and other things for years in anjuta without much trouble. We also used libsexy which wasn't supposed to be super stable either. If code is useful to us I don't see the point of not using it just because it hasn't been released in a 1.0 fashion. * Our policy was always to depend only on stable gtk+ version even in development releases and use conditional codes otherwise - I think that's fine. Actually we might think about using GtkRevealer in gdl and some point to slide in new docks.
(In reply to comment #16) > Yeah, but are they as big as we are? I think there are smaller in lines of code but bigger in number of users and they are official GNOME applications so any breakage due to libgd will have to be fixed. > The difference is that we wrote our code with our requirements, for both > features and stability, in mind. And we have full control over what goes into > it and when. With libgd, we might be able to control when we update it, but > all hell could break loose if we ever do update and aren't careful. I agree with this. > It could be no big deal, or it could be a total mess, kind of like > anjuta-extras was during the 3.0 cycle. Remember how almost everything in > there broke and I had to get rid of almost all of it before I could start > releasing it again? I'd rather that didn't happen to Anjuta itself. I think it's not the same because we don't need to update libgd while we have to work with all versions of Gtk+. And it's not history, the whole symbol db plugin crash with the latest version of Glib. I have committed, 10 days ago in the branch 3.8, the fix written by Carl. > Speaking only for myself, I don't have any issues with > GtkRevealer, but I understand your aversion to having to update GTK on what > seems like a constant basis. It's not for me, I compile Gtk+ from git. But I think it's useful that users can compile Anjuta from source. Most distribution provide Gtk 3.6, I think we should not require more for the moment. > I realize that at some point libgd might have things that are of more use to > us. I can't really predict what those things might be, but we should revisit > this issue every so often. If we find something really useful in some future > version of libgd, maybe one day the risks will be worth it. I agree with you about the current benefit of libgd but I think it could be more useful later and I haven't the same evaluation of the risk. But that's ok, we cannot always have the same ideas.