[04:29] <dmj726> What would be best practices for creating a publication for the Ubuntu Software Center
[04:41] <jo-erlend> dmj726, "publication"?
[04:41] <dmj726> like a book or magazine
[04:43] <dmj726> jo-erlend:
[04:43] <jo-erlend> right. I don't think there's anything too special about it. They get added to /opt/yourcomp/. I'm not entirely sure how they appear in users dashes, though.
[04:44] <jo-erlend> mhall119 probably knows.
[05:19] <dmj726> what does Unity do with link or directory types?
[05:20] <jo-erlend> dmj726, I don't understand that question.
[05:20] <dmj726> in the desktop entry file
[05:20] <jo-erlend> ...?
[05:21] <dmj726> type can be application, link, or directory
[05:22] <jo-erlend> I'm not entirely sure what directory does. But a link is handled as a link, and an application is handled as an application. I don't know what you're asking.
[05:29] <jo-erlend> I need to reboot.
[05:29] <jo-erlend> brb
[08:18] <SpamapS> Howdy! I'm trying to fix the aws-status appindicator that comes included with txaws...
[08:19] <SpamapS> (not an experienced gtk programmer so going is slow...)
[08:19] <SpamapS> At some point, the label from my indicator got "stuck" in my panel..
[08:19] <SpamapS> the process isn't running anymore.. so... what gives?
[08:20]  * SpamapS suspects perhaps a panel bug could be at play too
[08:39] <dpm> hi SpamapS, unfortunately, I cannot help on this one. You might want to ask ted when he's online, or alternatively ask also on http://askubuntu.com/questions/ask?tags=application-development
[08:39] <SpamapS> I haven't been able to reproduce
[08:40] <SpamapS> so its possible I just said the incantations wrong or crossed the streams or something
[08:41] <dpm> ah, right
[11:04] <jml> jo-erlend: hi
[11:04] <jo-erlend> jml, hi. :)
[11:05] <jml> jo-erlend: I saw your email to ubuntu-app-devel. I think you make an excellent point.
[11:05] <jml> jo-erlend: but I honestly have no good answers.
[11:05] <jo-erlend> neither do I, otherwise I would've suggested something specific.
[11:05] <jml> jo-erlend: heh heh
[11:05] <jml> jo-erlend: I figured if I started rambling on IRC that would be more likely to yield fruit than just sitting on your email like a mother hen.
[11:06] <jml> Or maybe that should be yielding eggs
[11:06] <jml> metaphors are hard.
[11:06] <jml> Anyway.
[11:07] <jo-erlend> however, I forgot to write about the positive side if we do put an effort into this. For instance; it is currently true that you cannot make a custom GTK TreeModel using Python. Now you know. And I'll remember having told someone about it. However, some time into the future, this problem will be fixed and I'll get notified by email when it does. I will not remember who I've told this to. So people are most likely going to keep thinking it's
[11:07] <jml> we've been talking a bit within Canonical about the Ubuntu "developer offering", where that's an umbrella term for the whole app developer picture: tools, API, SDK, etc.
[11:07] <jo-erlend> not possible, long after it becomes possible. If we had tracked this issue, then the fix would become well known much faster, leading to less confusion in the future.
[11:08] <jml> jo-erlend: huh. that sounds like a thing where stackoverflow or askubuntu would help a lot
[11:09]  * dpm was thinking that too
[11:10] <jo-erlend> it wouldn't. I ask why my program doesn't work, and the response is that I've done everything correctly, but there is a bug in Python/GTK that prohibits that kind of application from working. Two years later, the bug is fixed. Who will update the answers on stack?
[11:11] <jo-erlend> in other words; we are efficient in saying there is a problem, but the solution will go unnoticed. This is harmful.
[11:13] <jo-erlend> if, on the other hand, we link specific bugs to a "ubuntu-python-developer" project, then we will both have a way to get an overview of issues, but also know that solutions will be just as visible as the problem were.
[11:16] <jo-erlend> so I'm imagining something like this. You have a Ubuntu App Developer project. Underneith this project, you have sub-projects for toolkits, and under them, languages. So you'd have something like UAD > GTK > Python, UAD > GTK > C++, and UAD > Qt > Gambas. What do you think?
[11:18] <dpm> jo-erlend, let me add a comment on one of the points here: the point of stackoverflow is that it can be updated, and cleaned up! So to answer the question to who will update the answers on Askubuntu or Stackoverflow: either you or someone else affected by the problem
[11:18] <jo-erlend> if there is an issue with Python and GTK development, then there is also a problem with GTK development on Ubuntu. Further, there is a problem with app development on Ubuntu. But even if Python/GTK is problematic, it doesn't necessarily mean those problems exist with Vala or some other language.
[11:19] <dpm> jo-erlend, in a way, what you're proposing is quite similar to what we're doing with the ubuntu-translations project in LP, which has been working quite well
[11:19] <jo-erlend> dpm, yes, but that depends on manual work, that someone who is affected still cares enough to update, etc. You could say the same thing about email or IRC. If I really care, I can now make a note of everyone who is in this channel now, and when the problem is fixed, I'll remember to come here and tell you about it. But in reality, I know I won't. Bugs can be linked, however.
[11:20] <dpm> you need the same amount of dedication and work to find and link a bug as to update a stackoverflow answer :)
[11:20] <jo-erlend> I think the difficulty is defining workflows. Making a certain development method a supported development method with issues that can be tracked and worked on.
[11:24] <jo-erlend> dpm, only if you're very dedicated. I would possibily  be willing to do that. But you'd also have to maintain a list of distributions for that to work well. But we need to see it from the other angle; a user decides to learn how to write a program on Ubuntu. The first projects are easy, and the user slowly becomes more confident. Then he runs into a problem, and somehow finds out it's a bug. He then files a bug to the app-dev project, which
[11:24] <jo-erlend> can then help improve the bug description and file the bug at the right tracker.
[11:27] <jo-erlend> I mean; it took me a week to realize that there was a bug in the GTK GIR bindings. I had to spend quite some time figuring out exactly where to file a bug, and when I finally found it, it was already reported and had been known for months with no activity. Others in the community knows much more than I do about GIR bindngs and GTK+.
[11:33] <dpm> jo-erlend, I think having an ubuntu-app-devel project might be a good idea as an umbrella project. As I say, it's worked well for translations -> it has given more visibility to i18n/l10n bugs, and most importantly, it's helped creating a team of dedicated community members around the project. My main concern is about the sub-projects and spreading out too thin
[11:39] <jo-erlend> right. The details would have to be figured out. It's easy to make things too complicated. But we should at least track blockers. The program Gramps, for instance, can't be upgraded to GTK3 and GIR, because of the bug I've used as an example. My projects are probably going to be canceled, because the bug doesn't have a chance of getting the attention required to get it fixed. And though I'd want to, I don't have the time to go so deep into G
[11:39] <jo-erlend> TK+ development that I can fix it myself.
[11:42] <jo-erlend> and how many of these blockers are there? If I was unlucky enough to find the single one, then ok. It's annoying for me, but it might not be detrimental to app development in general. But if there are many and noone knows it, then it can have nasty effects in the long term.