Package Details: wingide 6.0.12.1.2-1

Git Clone URL: https://aur.archlinux.org/wingide.git (read-only)
Package Base: wingide
Description: Wing IDE Professional is the full-featured Python IDE for professional programmers.
Upstream URL: http://www.wingware.com
Licenses: custom
Submitter: None
Maintainer: greyltc
Last Packager: greyltc
Votes: 46
Popularity: 1.199633
First Submitted: 2008-03-13 17:00
Last Updated: 2018-05-22 14:37

Latest Comments

greyltc commented on 2018-02-22 18:23

I can't help with your fcitx input method problem.

aaronchn commented on 2018-02-07 18:18

How to use the fcitx input method in wingide? I have already installed fcitx-qt4 and fcitx-qt4, but still not work.

As I know, Wingide used isolate Qt5.5 instead of system-provided Qt, With some talk [ https://www.allanswered.com/post/anxo/solving-the-issue-unable-to-input-chinese-in-wing-ide/ ], I also try [# sudo cp /usr/lib/qt/plugins/platforminputcontexts/libfcitxplatforminputcontextplugin.so /opt/wingide/bin/runtime-qt5.5/plugins/platforminputcontexts/], Trouble still.

greyltc commented on 2017-08-15 15:51

Pro (see package description text).

ShalokShalom commented on 2017-08-15 15:43

Which version is that? Personal? 101?

greyltc commented on 2017-01-09 15:26

I've updated this to ver 6.0. Upstream has dropped support for i686.

DescartesHorse commented on 2016-06-28 23:46

Successfully "downgraded" - thanks for posting updates to let us know!

greyltc commented on 2016-06-18 12:34

I've fixed an epoch mistake I made in the PKGBUILD so you'll have to effectively downgrade wingide to go from 5.1.11 --> 5.1.12
Sorry about that.

von commented on 2016-05-11 09:25

It's up to you, but breaking versioning without a good reason (“it doesn't look nice anymore” is not a good enough reason imo) is a really bad practice, so the solution A would be more community friendly.

greyltc commented on 2016-05-10 11:40

Oops. I thought pacman took pkgver to be more important than epoch when deciding when to upgrade. So I guess there are two possible solutions to the problem I've created here:
A) stay on epoch 3 forever, preserving automatic upgrades
or
B) remove epoch from the PKGBUILD now, bringing the package's version number back to the way it should be, thus breaking automatic updates. I'd add a comment here instructing users to "downgrade" to the latest version. Users would get an upgrade nag message every time they launch the IDE and eventually they'll come here wondering why I haven't upgraded the package and read my downgrade instructions to get back on track.

I lean towards option B.

von commented on 2016-05-10 10:49

It goes against the versioning conventions. You have _wingrel variable, you should just add patch level there (1->1p1, 1p1->1p3, for example). Resulting package already has an upstream rel (albeit separated from the upstream version by a dot) value in its version anyway. Ideally epoch should not be used at all, but now there is no going back (since omitting it will make newer versions lesser than epoch'ed ones).

Epoch approach will stop working the next minor upstream version you release (say, it'll be 5.1.12-1 with no patches, you release it as 5.1.12.1-1, and it's considered 0:5.1.12.1-1 by the package manager, which is lower than current 3:5.1.11.1-1).

All comments