[prev in list] [next in list] [prev in thread] [next in thread]
List: pykde
Subject: Re: [PyQt] Problem with resource imports in pyuic generated files
From: Elvis Stansvik <elvstone () gmail ! com>
Date: 2016-02-17 5:06:10
Message-ID: CAHms=eZcLi=zaBxWM8FAXv8D4QH=a4DQ3_B14GCFsyN1raBMQQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Den 16 feb 2016 10:00 em skrev "Baz Walter" <bazwal@ftml.net>:
>
> On 16/02/16 18:56, Elvis Stansvik wrote:
>>
>> 2016-02-16 19:54 GMT+01:00 Elvis Stansvik <elvstone@gmail.com>:
>>>
>>> 2016-02-16 19:35 GMT+01:00 Baz Walter <bazwal@ftml.net>:
>>>>
>>>> So the python package directory contains python modules and nothing
else.
>>>> The resource module generated by pyrcc just goes in the same directory
as
>>>> the ones generated by pyuic, which solves the import issue.
>>>
>>>
>>> Ah yes, probably a good idea to to break the .ui files out of the
>>> python package as well. Thanks.
>>>
>>> For now, I'll have to keep the generated _ui.py and _rc.py in the same
>>> package. This is okay, but I would rather have them split up (e.g. a
>>> ui/ or perhaps forms/ package with the .ui files, and a resources/
>>> package for the resources). So for me, something like a
>>
>>
>> I should say, the reason I'd prefer to be able to do this is that some
>> of my resources are not really "UI" things per se, but more like
>> static application data, so it would make more sense to have a general
>> "resources" package for them.
>>
>
> The modules generated by pyuic will probably be the only ones that
explicitly import the resources module. What would be the point of a
separate sub-package? From a programming point of view, the only namespace
that matters is the one provided by the resource system itself - and the
best place to organize that is the qrc file (it has support for aliases, if
needed).
That's a good point. I think the reason I wanted a resources package is
that I'm abusing the resource system a little, by having
icons.qrc
images.qrc
rock_types.qrc
mineral_types.qrc
...
Not all of which are used only from UI forms, so some would need to be
imported from manual code, such as in the item delegate I pasted.
I realize now that that's not such a great idea, and will stuff it all in a
single resources.qrc.
I was structuring the contained files across separate directories anyway,
which gives nice namespaces in the :/foo paths used.
Thanks for the input!
Though, Phil, I cannot help but ask: Would you accept a patch for a
--resources-package <package> flag to pyuic? When given, it would generate
resource imports from the named package instead of assuming resources were
generated into the same package as the _ui.py.
Elvis
>
>
> --
> Regards
> Baz Walter
> _______________________________________________
> PyQt mailing list PyQt@riverbankcomputing.com
> https://www.riverbankcomputing.com/mailman/listinfo/pyqt
[Attachment #5 (text/html)]
<p dir="ltr">Den 16 feb 2016 10:00 em skrev "Baz Walter" <<a \
href="mailto:bazwal@ftml.net">bazwal@ftml.net</a>>:<br> ><br>
> On 16/02/16 18:56, Elvis Stansvik wrote:<br>
>><br>
>> 2016-02-16 19:54 GMT+01:00 Elvis Stansvik <<a \
href="mailto:elvstone@gmail.com">elvstone@gmail.com</a>>:<br> >>><br>
>>> 2016-02-16 19:35 GMT+01:00 Baz Walter <<a \
href="mailto:bazwal@ftml.net">bazwal@ftml.net</a>>:<br> >>>><br>
>>>> So the python package directory contains python modules and nothing \
else.<br> >>>> The resource module generated by pyrcc just goes in the \
same directory as<br> >>>> the ones generated by pyuic, which solves the \
import issue.<br> >>><br>
>>><br>
>>> Ah yes, probably a good idea to to break the .ui files out of the<br>
>>> python package as well. Thanks.<br>
>>><br>
>>> For now, I'll have to keep the generated _ui.py and _rc.py in the \
same<br> >>> package. This is okay, but I would rather have them split up \
(e.g. a<br> >>> ui/ or perhaps forms/ package with the .ui files, and a \
resources/<br> >>> package for the resources). So for me, something like \
a<br> >><br>
>><br>
>> I should say, the reason I'd prefer to be able to do this is that \
some<br> >> of my resources are not really "UI" things per se, but \
more like<br> >> static application data, so it would make more sense to have a \
general<br> >> "resources" package for them.<br>
>><br>
><br>
> The modules generated by pyuic will probably be the only ones that explicitly \
import the resources module. What would be the point of a separate sub-package? From \
a programming point of view, the only namespace that matters is the one provided by \
the resource system itself - and the best place to organize that is the qrc file (it \
has support for aliases, if needed).</p> <p dir="ltr">That's a good point. I \
think the reason I wanted a resources package is that I'm abusing the resource \
system a little, by having </p> <p dir="ltr">icons.qrc<br>
images.qrc<br>
rock_types.qrc<br>
mineral_types.qrc<br>
...</p>
<p dir="ltr">Not all of which are used only from UI forms, so some would need to be \
imported from manual code, such as in the item delegate I pasted.</p> <p dir="ltr">I \
realize now that that's not such a great idea, and will stuff it all in a single \
resources.qrc.</p> <p dir="ltr">I was structuring the contained files across separate \
directories anyway, which gives nice namespaces in the :/foo paths used.</p> <p \
dir="ltr">Thanks for the input!</p> <p dir="ltr">Though, Phil, I cannot help but ask: \
Would you accept a patch for a --resources-package <package> flag to pyuic? \
When given, it would generate resource imports from the named package instead of \
assuming resources were generated into the same package as the _ui.py.</p> <p \
dir="ltr">Elvis </p> <p dir="ltr">><br>
><br>
> -- <br>
> Regards<br>
> Baz Walter<br>
> _______________________________________________<br>
> PyQt mailing list <a \
href="mailto:PyQt@riverbankcomputing.com">PyQt@riverbankcomputing.com</a><br> > <a \
href="https://www.riverbankcomputing.com/mailman/listinfo/pyqt">https://www.riverbankcomputing.com/mailman/listinfo/pyqt</a></p>
[Attachment #6 (text/plain)]
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic