1
loading 2014-06-22 15:13:41 +08:00 via iPhone
vs就可以啊,qt
|
2
hahastudio 2014-06-22 15:19:02 +08:00 1
PyQt有个Qt Designer吧
虽然不是很好用,但是拿来画界面还是可以的 |
3
da_a 2014-06-22 16:26:57 +08:00
wxdesigner
http://www.wxdesigner-software.de/ |
4
em70 2014-06-22 16:35:46 +08:00 via Android
有,但都很难用,不要考虑这条路了,每个语言都有其擅长的地方,py不适合做gui
|
5
ericls 2014-06-22 17:03:03 +08:00
glade
qt designer wx |
6
billlee 2014-06-22 17:20:51 +08:00 1
@em70 Python 很适合做 GUI, PyQt 和 PyGTK 都很好用。BitTorrent, Dropbox, TortoiseHg 等很多桌面软件都是用 python 写的。
|
7
em70 2014-06-22 18:04:38 +08:00 via Android
@billlee 如果py很适合gui,那c#,Delphi算什么,py只能说能做gui,但还是麻烦,跨平台gui我觉得还是用web好一些
|
8
batfree 2014-06-22 18:33:31 +08:00 via Android 1
做了这么多gui相关的应用,最后都回归到自己写了。ide生成的都很不好看,冗余代码多,名字不好识别,调整不灵活,还是回归手写靠谱
|
9
leeoo 2014-06-22 20:45:08 +08:00 1
安装好PyQt后会有个Qt Designer,可以用来拖拽界面,控制逻辑自己写。
PS: PyQt做界面用起来还是比较舒服的,连我一个用C#做界面的同事也感叹说Qt那套Signal & Slot的确是好东西。 |
10
clino 2014-06-22 22:43:14 +08:00
wx 还有一个 wxformbuilder
|
11
incompatible 2014-06-23 00:07:00 +08:00 via Android
|
12
sandtears 2014-06-23 01:29:37 +08:00 1
@incompatible 这样打包的少么?我看见过好几个 Node.js 的应用就是这么干的
|
13
em70 2014-06-23 03:04:08 +08:00 via Android 1
@incompatible 跨平台的话,思路就应该改变,尽量用云计算+web表现层构架,页游的例子就不说了,像qq以前还开发了Linux版,但后面停止开发用web qq代替Linus版了。只有下载相关应用,web搞不定,必须客户端,其他应用应该都有办法web解决。
|
14
wzzyj8 2014-06-23 07:20:39 +08:00 via Android 1
@incompatible 现在web打包很多的,除了web前端代码比较成熟和具有普适性强以外,更重要的是因为web前端的工资便宜啊!!哎说多了都是泪
|
15
incompatible 2014-06-23 09:43:59 +08:00
@em70 你这只是web应用的场景,不能适用到所有方面
你告诉我,像eclipse、intellij idea这样的跨平台的应用,如何用web做? |
16
incompatible 2014-06-23 09:46:03 +08:00
@sandtears 以前只见过在android和ios上这么玩的,今天长见识了 nodejs逆天啊!!
|
17
em70 2014-06-23 10:13:41 +08:00 via Android
@incompatible 没说任何应用都可以web化,比如下载应用就不行,但绝大部分软件是可以的。我觉得ide的web化只是时间问题,高速网络环境下html5完全有机会做到很好的体验。但有几个程序员有机会做ide呢?
|
18
incompatible 2014-06-23 10:53:56 +08:00
@em70 你的前提(高速网络环境下)根本就是靠不住的 在没有network connectivity的场景下(举个例子:在一家人流拥挤、通信基站拥塞导致无法提供4g、3g和edge信号的超市里消费完毕,打开记账app想记一笔),哪能办?你的所有app全部完蛋了,不能用了!
另:你我在这里讨论了半天跨平台应用,实际上讲的根本不是一个东西 我在讲本地应用,你在讲web服务 我相信楼主想用ide拖拽出来的是一个不强制需要网络连接,双击点开桌面上的图标就可以使用的软件(如:ubuntu tweak、parallel desktop、intellij idea、word,garage band) 而你说说的跨平台,只不过是web based service套了一层html5的壳而已 回到IDE的话题:如果用你的web服务+html5的思路来做,那么我有几个问题: 1. 如果我的工程有20w行代码,要为它们全部构建AST的话,是在本地做还是在服务端做? 2. 你是否有信心解决浏览器兼容性问题? 3. 实现起来是否真的比使用java语言更简单? 4. 个人版intellij idea只要199美刀,下载到本地计算机安装后即可使用。你的服务打算如何部署?怎么收费?可用性几个9?我的代码是机密,难倒也要放到你的服务器上? |
19
lm902 2014-06-23 11:40:14 +08:00 via Android
IronPython+Blend+WPF+XAML
|
20
jasontse 2014-06-23 11:40:21 +08:00 via iPad
|
21
lm902 2014-06-23 11:41:52 +08:00 via Android 1
@em70 下载也可以做成Web,参考mega.co.nz
|
22
em70 2014-06-23 13:28:35 +08:00
@incompatible 我的观点是大多数桌面软件是可以WEB化的,当然会有软件不能WEB化,讨论这种极端情况没意义。如果一个软件要python做GUI,那么大多有WEB化的方案可以选择。另外我们说的都是桌面软件吧,移动应用那是另一个世界,那是APP的天下,不需要跨平台。
单独说IDE 1.服务器足够强,WEB只是表现层,高速网络下肯定没问题 2.浏览器在快速发展,不能用现在的技术看未来,兼容性问题肯定不是问题,程序员手上一定有最新最快的浏览器。 3.IDE云端化我觉得不比本地复杂,只要编译器成熟,表现层的问题都不是问题,有足够多的前端牛人,python,java的GUI牛人真没见过。 4.商业模式一定比一次性授权好,可以多种模式,按月付费或者基本功能免费,高级功能付费等。或者完全免费,基于WEN很容易配套一个社区,社区的盈利模式就很多了,卖个书,找个工作,跟v2ex一样。看看现在几个人IDE正版啊,一次性授权未来必死。 5.安全性。我们用163,QQ,gmail发送收取机密邮件,怎么就不担心安全性呢。就算真的有隐患,企业自己做私有云就行了,这样IDE还能分2种版本卖 |
23
yangff 2014-06-23 13:46:04 +08:00
跨平台容我说一句,OpenGL自绘保平安/。\
|
24
yangff 2014-06-23 13:48:10 +08:00
@em70 绝大多数的软件都不能云端化,简单的说一句,我要在随时随地随刻能够使用你的应用,要不笔记本要电池干嘛,有wifi有网线的地方会没有插座?
|
25
em70 2014-06-23 14:08:24 +08:00 via Android
@yangff 你每天开电脑用得最多的肯定是浏览器吧,连大型RPG游戏都能云端,还有什么不能的。
你得用发展的眼光看问题,未来10年,20年,难道4g,5g做不到白菜价吗,全天候互联网一定会出现的,网络不是问题的。 另外移动应用那是另外一个世界,不能跟桌面混为一谈 |
26
incompatible 2014-06-23 16:30:13 +08:00
@em70 你说的web化的东西不叫桌面软件,叫web+服务
凡是涉及到服务的东西就会有运维成本 依然拿ide举例: 我付了钱,jetbrains只要提供给我license,我就可以开始下载安装intellij idea并开始使用了。 按你的思路,我购买你的ide服务,要定期付钱,你要保证提供给我高可用性的ide服务。你的服务器宕机了怎么办?被黑客入侵、删光所有数据怎么办(参考最近的codespace事件)?服务器不够用了怎么办? 我的意思不是这些问题无法解决或很难解决,而是这些都是需要金钱或人力成本的,并不是一件轻松的事儿,起码不会比随手在网上打出一句”大多数桌面软件是可以WEB化的“轻松 |
27
incompatible 2014-06-23 16:31:45 +08:00
@em70 我不太明白为什么软件不能web化居然成了极端情况
前面举例里的软件可能你没有听说过或不太了解 我举个最简单的例子: 我想写一个gui应用来管理本机的host配置。 这种场景用web化能做到吗? 简直就是笑话 |
28
yangff 2014-06-23 16:56:44 +08:00 1
@em70
不是,是sublime text. 当然浏览器我也不常关,主要原因是chrome的恢复标签页越来越垃圾了。 WebGL至少这1、2年内不会用可用性,同时大型RPG不能在浏览器跑,如果你认为页游算大型RPG游戏当我没说,至少你没见过魔兽世界或者星际争霸做成网页游戏吧。 没错是有直接把llvm在js上跑的东西,不过因为莫名其妙的内存泄露导致可用性同样=0, 你玩个游戏十几分钟要挂一次你玩得下去啊,而且这个问题一直都在,从来没修复过。 你可能觉得js性能不好你在云端计算好再下放下来,没用的,早就有人做过了,而且效果,呵呵呵,什么时候我们家用宽带能有个几百兆到G级,再考虑吧。 最后,如果在浏览器上跑NaCl、ActiveX、Java之类的东西我不如直接做成桌面应用。 ----------- 要做到尽可能好的桌面体验,OpenGL / DirectX自绘的地位几乎不可撼动。 ----------- nodejs + chromium看起来很美那些个demo不知道高到哪里去,好像也有人用类似技术捣鼓出什么atom.io是吧?css3+js让一堆web前端的很爽是吧?但是我就告诉你用这坑爹玩意在稍微早几年的机子上卡的简直不能看,无框窗口+自绘标题栏,drag起来跟拉破车一样,稍微一点动画效果分分钟cpu跑上25%,最高fps还只有10几,最坏的情况直接个位数。 当然在i7 + gtx670上还是可以流畅运行的,只是稍热一点。 ----------- 当然计算机的性能会发展,迟早手机的性能都能达到i7的程度是吧? 但是我现在问你,如果云端的应用都能做到这么好的效果,桌面应用不是更好?? 云端可以0.01s给你响应,桌面不是只要0.0000001s?你不能把服务器部署在用户的家门口吧。 这样看没有差别,操作100次呢? 云端要1s给你响应,桌面是0.00001s,明白我的意思吧? ----------- 对了,浏览器可以用来写p2p的下载工具,因为有个东西叫做webrtc. ----------- 确实Web都可以做,但是不管怎么看在任何方面都没有优势。 Linux版本的QQ?你以为腾讯开发不出,维护不了Linux版本吗?? 更何况WebQQ简直是垃圾中的垃圾,不知道他们的团队知不知道他们的杀马特QQ内存泄露。 ----------- 最后,跨平台只是逗你的罢了,指望一份代码 / 设计在所有平台上运行的开发者,我也只能送“呵呵呵呵”四个字了。 ----------- 你要说这是未来,我不如相信未来是易语言的。 |
29
em70 2014-06-23 18:21:20 +08:00 1
@incompatible
我们的分歧主要是软件应用范围造成的,我考虑的更多是给普通人用的软件,你考虑的更多是程序员的软件. 如果是程序员圈子内的软件,用什么技术都无所谓,界面多烂,运行多卡咱都不在乎,需要什么环境,需要什么库支持,咱自己都能安装啊.这个领域我完全同意你的意见,python,java,QT都挺好的,我也很喜欢。 但世界上99%的人不是程序员吧,99%的软件也不是给程序员用的吧. 软件的主体其实在普通人这里.民用级软件要跨平台,除了下载软件和系统优化软件,大多数情况下WEB是最好的选择,因为对环境基本没要求,部署成本几乎为0,而且商业模式很灵活(月付只是一种,QQ会员,收费邮箱不一样大把人给钱。免费增值模式也 可以做很好)。google早就看到了WEB APP会成为PC的未来,所以他做了 chrome os。google,微软不也在拼web版的office么。 |
30
em70 2014-06-23 18:27:49 +08:00
@yangff 现在除了暴雪,腾讯,还是几家公司敢做端游的? 咱不要老站在程序员或者发烧友的角度看世界,我们是要给全世界人写软件的,老百姓需要的就是简单,简单再简单。云计算零部署的优势,对普通人吸引力太大了,0.1和0.0001s的区别,他们不在乎。
|
31
jyzhengqian 2014-06-23 18:39:00 +08:00
Puthon Tools for Visual Studio 2013
|
32
jyzhengqian 2014-06-23 18:45:14 +08:00
@jyzhengqian 唔,我理解错楼主的意思了,而且我拼错了 = =
|
33
yangff 2014-06-23 19:11:39 +08:00 via Android
|
34
yangff 2014-06-23 19:19:15 +08:00 via Android
@em70 怎么没几家?大的育碧ea,小的 mojang,算上主机还有骚尼,在你眼看都不是游戏厂商了吗?
你让他们把3A大作搬到页游试试?Java运行的mc虽然可以在浏览器运行和浏览器一毛钱关系都没有。类似的还有unity3d。 cocos2dx倒是有wengl不过也只能呵呵了。 更何况你忘了一大票独立游戏作者? 能放到页游的,只有页游,更何况现在页游被手游按在地上打,你还搬出来说。。 |
36
incompatible 2014-06-24 00:44:21 +08:00
@em70 朋友,我认同你关于分歧的总结。的确有很大一部分比例的软件不是给程序员用的。 但是,这一大部分软件中也不是所有的都可以web化
我主业是码农,业余时间是一名贝斯手,偶尔会使用一个叫cubase的软件录一些小样 该软件对声卡要求较高,在windows下要求声卡支持asio 2.0,在mac下要求声卡支持core audiro 我不认为这样一款软件可以被web化。html5恐怕无法支持通过上述两种协议来访问声卡 并且,录音时如果要实时监听,那么理想的latency应当小于10ms。目前的主流配置的pc+声卡基本可以做到:“A/D转换+传输via usb+cpu渲染+传输via usb+D/A转换”控制在10ms左右。 如果采用你的web服务的架构,那么就要求24bit*192khz(假设我们采用这样一个高规格采样率)约等于4M/s的数据的如下过程:“A/D转换+传输via usb+传输 over internet+服务端渲染+传输over internet+传输 via usb+D/A转换”的latency可以控制在10ms内 我认为即便在遥远的未来,从带宽、延迟、QoS(重要)的角度来看这也是一个impossible mission。 另:我前面已经说过了,你说的东西不叫软件,叫服务。虽然web化以后客户端的部署成本基本为0,但是服务端的部署和运维成本你不应当忽略。 |
37
incompatible 2014-06-24 01:06:02 +08:00
@em70 再多说点
一个软件/应用,说白了就是展现层/交互层+业务逻辑 你的主张是使用web作为展现/交互层、业务逻辑以服务的形式提供,理由是web部署成本为0、前端大牛多、开发起来容易,业务逻辑无论多复杂只要服务器够强大那都不是事儿 但是我在这样的结构里看到很多局限性: 1. 前端与后端交互严重依赖network connectivity。这是致命硬伤 2. 后端服务化,就需要考虑服务的capacity和availability。把这些问题丢给云计算来解决是一个好主意,但别忘了云计算服务商不是慈善家,你需要付¥给人家 3. 业务逻辑放在服务端,会带来很多功能和性能上的局限性。你无法访问声卡,无法访问cpu的虚拟化指令、无法访问硬盘,etc。以及前面我举的例子:为20w行代码构建AST。这件事开销并不小,放在客户端来做很合适。你却非要花费用¥买来的宝贵的服务器资源来做。免贵姓雷单名一个锋吗? 4. 前端的性能问题。参见28楼 考虑到我上面提到的局限性,你还认为未来的趋势只会是一个web+服务吗? mac pro会淡出历史舞台然后chromebook一统江湖吗? |
38
em70 2014-06-24 02:05:15 +08:00 via Android
@incompatible 我完全赞同你的说法,我从来没说过所有软件都适合web,我一直强调是大部分,而不是所有。大部分这个词汇理解因人而异,也没必要争论了。
我想说的是软件即服务是最近10年来发展起来的非常重要的思想,这是互联网思维对软件业的改造,大型软件公司都在往这个方向发展,不应该把软件和服务严格区分开。 ok,到此为止吧,很高兴和你讨论。 |
39
jianghu52 2014-06-24 09:12:52 +08:00
.net的IDE之所以能那么流畅的拖拽,是因为他有一个巨大的freamwork库在后面支持。python要想做到这一点就很难。所以目前好像就QT能拖拽一下。
事实上我觉得前端用html+css已经能做的很好了。 |
40
FrankHB 2014-06-24 16:09:36 +08:00
@em70
“大型软件公司都在往这个方向发展”说明他们发现这里方便他们捞钱,而不必然说明用户需求如何或者整个软件业就应该往这个方向发展。 顺便: http://www.gnu.org/philosophy/who-does-that-server-really-serve.html |
41
em70 2014-06-24 16:56:01 +08:00 via Android
@FrankHB 迅雷和快车就是互联网思维和传统软件两种思想的典型代表。迅雷把软件做成了服务,体验秒杀快车,衍生大量商业模式,马上上市了。快车就只做软件,现在还有人想起他吗?
|
42
ryanking8215 2014-06-25 09:14:31 +08:00
大家把web局限在BS架构上了,不要忘了还有nodejs-webkit,或者类似的存在。
native application也可以用web技术来实现,不是BS架构。 比如上朋友举例一个音频采样软件,ui表现层可以用web技术实现,native api使用nodejs+addon来实现。 当然,现在nodejs-webkit,atom-shell还在完善的过程中,我认为这个是趋势。 |
43
FrankHB 2014-06-29 02:04:30 +08:00
@em70 别拿“思想”粉饰对用户需求的注意不足来分散注意力了。本体论意义上就不通。
迅雷当年的成功跟你所谓的“互联网思维”有多少关系?P2SP就比直接下载更“互联网”了?是不是迅雷服务器挂掉了就都不能下载了然后用户会更高兴? |
45
FrankHB 2014-06-29 02:39:04 +08:00
@em70
“其一是不懂资本市场运作,不会借助资本市场的力量快速发展自己。其二,团队速度太慢,创始人是海外背景,一直不紧不慢的打造产品。” 结果就是用户发现快车不够迅雷好用,所以用脚投票把快车踹一边去了。 顺便…… “迅雷创始人在谈及自己的创业史时提到,感谢魔兽世界,当年迅雷被网际快车(FlashGet)压制的时候,网际快车创始人侯延堂迷恋魔兽世界,停止更新软件长达一年,市场份额被迅雷迅速占领。” 2333 本来都是基于互联网的服务实际上要说是不是互联网精神也过于含混了。这样吧,你说说迅雷怎么表现得和Web相关?是不是网页版迅雷就比客户端的好用? |
46
em70 2014-06-29 03:29:18 +08:00
@FrankHB 你其实不了解为什么迅雷下载快。迅雷从2003第一个版本开始就在做大数据收集,用迅雷下载成功任何一个文件,会计算文件md5值和下载地址配对一起发回迅雷服务器保存。这是一个非常海量的数据
当采集md5和url配对数据到一定程度的时候,迅雷对数据做了分析,把相同md5值的URL汇总在一起形成一个资源列表。 用户用迅雷下载一个地址的时候,迅雷先不急于下载,先向服务器查询这个URL所属的资源列表,拿到这个资源列表就可以从多个不同的源来下载这个资源,所以就算这个URL已经过期,仍然可以下载。而且因为多个源头下载,就算这个URL服务器不行下载慢,其他源可能速度很快啊,所以迅雷下载很多文件都可以很快,而且能下死链。这个体验太厉害了,当年用户有多疯狂的热爱迅雷不用我多说了吧。 再看看快车,2007年前就是一个单纯的下载软件,后面没有任何服务,只有一招多线程来提升下载速度,如果URL源本身不行,那就会失败,如果URL本身速度慢,那开10线程也快不了。体验越来越差 互联网思维简单的说就是把一切东西做成服务,迅雷10年前就用互联网思维在做一款下载软件,可以说迅雷软件其实只是迅雷服务的一个入口,真正强大的不是迅雷软件本身,而且迅雷后台的服务器集群,如此海量的数据分析,这是不亚于百度搜索引擎的技术。正因为迅雷对大数据,云计算的技术积累,2009年顺势推出离线下载服务,成功找到下载软件商业模式,后面做游戏,做视频,盘子越来越大,就上市了。 目前中国市场上牛逼的客户端:QQ,360,迅雷,快播等等等等全部都是软件只是入口作用,背后是强大的服务器做支撑。这就是互联网思维对软件业的改变,是历史潮流,不以个人意志而转移。 |
47
FrankHB 2014-07-07 19:23:13 +08:00
@em70 是你不懂吧。早就给你说了P2SP,这都看不出来么。你倒是解释一下,为什么依赖中心存储节点的网络更“互联网”?如果说SaaS……那也不是现在鼓吹的一些典型服务(引用RMS的术语叫SaaSS),因为最终下载还是得到用户控制的节点上。这又和纯P2P或者直接下载有多少本质区别?
|
48
FrankHB 2014-07-07 19:37:57 +08:00
@em70 我现在发现观点的差异主要在哪了:你是站在服务商的角度来说的,而我是站在用户的角度上说的。……那不废话么,要是没有任何用户依赖这些服务,服务商自然就嗝屁白搞了,没法套利,所以自然要鼓吹用户尽量利用这些东西,然后他们好赚钱。
问题是注意你选择的材料中两者的主次。 对于用户来说,搜索/内容服务或者其他杂七杂八的东西,这本身就不是一个下载客户端或者即时通信软件的主要功能定位。服务商如何扩展服务立足点首先在于他们自己的需求(有资源,当然应该拿来营销而不是空置——如果真能赢利则应该加大投入),而不尽然就是用户的需求(解决特定的问题,找找看有什么附加值是顺便)。当然,有些用户也乐于选择使用这些附加功能,但显然是次要的,而且这部分用户中有很大一部分其实对自己的需求都没认识明确,被服务商利用罢了。 还有互联网倒罢了,为什么就是“Web”(比如Web界面)?的确这些客户端有使用到Web技术,但这更多是一种偷懒和现实妥协(比如成本)。技术本身并没有限定这样的软件甚至服务本身非跟Web搭边不可。 |
50
wizardforcel 2016-05-15 12:03:45 +08:00
@em70 “缺个设计器”都能叫“不适合做 GUI ”?真搞笑。
你告诉我 Python 哪里不适合做 GUI 了? Python 自带反射,写 UI 的时候爽到飞起,比起 C++要用丑陋的宏来凑合的办法高到不知道哪里去了。 |