Honestly? They look dated. They look like a program from 2002.
I am sure I can make them nicer, BUT.... is it really worth the problem?
For example, here's the kind of things I have to do to show the title in
bold and the author in normal text:
f1 = painter.font()
f2=QtGui.QFont(f1)
f2.setWeight(QtGui.QFont.Bold)
fm = QtGui.QFontMetrics(f2)
h2 = fm.height()
text1 = "%s"%(book.title.title())
text2 = (u'by '+(u', '.join(a.name for a in
book.authors) or u'Unknown Author'))
painter.setFont(f2)
painter.drawText(
QtCore.QRect(r.x()+128, r.y()+2,
r.width()-128, h2),
QtCore.Qt.AlignLeft,
text1)
painter.setFont(f1)
painter.drawText(
QtCore.QRect(r.x()+128, r.y()+2+h2,
r.width()-128, r.height()-4-h2),
QtCore.Qt.AlignLeft,
text2)
return
While if it were a webkit view, I would just put three tags there. So, I
want to try switching to or at least offering as an alternative,
HTML-based listings.
The one problem I predict is that with a few thousand books, a HTML
based listing may not perform well, but that can always be solved by
pagination
What do you guys think? As a bonus it will look more like the store plugins.
Hehe, I agree.
> While if it were a webkit view, I would just put three tags there. So, I
> want to try switching to or at least offering as an alternative, HTML-based
> listings.
We're this close to turning Aranduka into a webapp, or an Adobe Air app hehehe.
> The one problem I predict is that with a few thousand books, a HTML based
> listing may not perform well, but that can always be solved by pagination
>
> What do you guys think? As a bonus it will look more like the store plugins.
It seems that webkit could make things easier and prettier, so I would
agree with switching.
If we do so, it would be a good time to organize our HTML templates a
little better. From what I've seen so far, we have some chunks embeded
on the python code and there are some other separated html files. We
should clean that up. Maybe we can add a function to the very basic ui
module.
One question: if we switch to webkit on shelf views... what will
happen to the context menu?
> If we do so, it would be a good time to organize our HTML templates a
> little better. From what I've seen so far, we have some chunks embeded
> on the python code and there are some other separated html files. We
> should clean that up. Maybe we can add a function to the very basic ui
> module.
>
> One question: if we switch to webkit on shelf views... what will
> happen to the context menu?
Well, it won't be there anymore.
Or maybe we can implement it but it's going to be a pain.
That's always good.
> QML is another option, but I am not very good at it.
Its wikipedia page makes it look very hard :P
>>> The one problem I predict is that with a few thousand books, a HTML based
>>> listing may not perform well, but that can always be solved by pagination
>>>
>>> What do you guys think? As a bonus it will look more like the store
>>> plugins.
>>
>> It seems that webkit could make things easier and prettier, so I would
>> agree with switching.
>
> I will start an alternative plugin so we can see how it works.
Ok
>> If we do so, it would be a good time to organize our HTML templates a
>> little better. From what I've seen so far, we have some chunks embeded
>> on the python code and there are some other separated html files. We
>> should clean that up. Maybe we can add a function to the very basic ui
>> module.
>>
>> One question: if we switch to webkit on shelf views... what will
>> happen to the context menu?
>
> Well, it won't be there anymore.
> Or maybe we can implement it but it's going to be a pain.
I'm thinking that currently we have 4 options in the context menu:
open, edit, delete and convert.
As long as those are the options, we could have little icons fading in
when you move your mouse over a book. I think Plasmoids had something
like that.
But if we need to add more options it can get more complicated.
We can use links like in the guesser too.. but is cooler if we do
something like the plasmoids.. :-)
Besides doing this or not, I think it's a good idea to organize our
HTML templates..
--
Ramiro Algozino
If a plugin needs a template, where should it be? I say in the plugin's
folder.
if the app wants a template, I say we create a templates folder and put
it there.
But yes, templates inside the code should go away.
I think we're on the same page here.
Agree 100%, also I think we need to start using HTML tags correctly,
like <h1>, <p> and friends.. what do you think?
--
Ramiro Algozino
Sorry, I didn't want to mean that. If we are going to use CSS, it
would be better if we use (i.e.) <h1> tag for BookTitles, <h2> for
Authors, <p> for tags and so on..
--
Ramiro Algozino
I'm not an expert either, so let's we say what's good! hehehe, now
seriously, I propose to make a convention on the html tags so we can
tune the CSS later, for example:
Let's say the <h1> html tag is for the book title, then we can tune
the CSS so the <h1> tag has a 12px font and has red color.
What do you think guys?
--
Ramiro Algozino
We could check if there's any microformat [0] for this. I mean, if
we're going define a format, we could check if there isn't a standard
that we could use :-)
Of course this makes sense mostly to have clean-meaningful code, but
it's not critical since we won't be having other applications crawling
our HTML, right?