21.
eski "çin malı" söyleminin ne kadar boş hale geldiğini gösteren dil modelidir.
devamını gör...
22.
#3371464 "bu chatgpt'nin egosuzluğu da artık bıkkınlık veren cinsten" diyecektim ki son paragrafta çaktırmadan üstü kapalı şekilde kendini övmüş kerata.
devamını gör...
23.
herkes chatgpt ile kıyaslamış ama deepseek' in asıl olayı modeli bilgisayarınıza lokal olarak kurup yada iç networkünüzde bir server' a kurup eğitip kendi modelini oluşturabilmeniz.
yani sürekli xgpt ye para vermeden huggingface yada benzer sitelerden datasetleri indirip veya kendi datasetlerinizi oluşturup bu modeli spesifik işler için eğitip kullanabilirsiniz.
lm studio
bunu bilgisayarınıza indirin açılışta size soracak tavsiyem deepseek' in 1.5 milyar işlem kapasiteli olan sürümünü indirin.
sonra huggingface e gidip beleş modellere bakın indirin işletin.
yani öyle chatgpt den daha iyi falan fişmekan değil mevzu 8 gb vramli 4060 lı bilgisayarınızda iyi kötü çalışabilen bir yapay zeka olabilmesi. devrim yaptığı yerde burası zaten.
hala siz server offline, chatgpt ye sordum falan diyorsunuz da kendi işlerinize özel bir yapay zeka eğitmenin ne demek olduğundan bihabersiniz.
yani sürekli xgpt ye para vermeden huggingface yada benzer sitelerden datasetleri indirip veya kendi datasetlerinizi oluşturup bu modeli spesifik işler için eğitip kullanabilirsiniz.
lm studio
bunu bilgisayarınıza indirin açılışta size soracak tavsiyem deepseek' in 1.5 milyar işlem kapasiteli olan sürümünü indirin.
sonra huggingface e gidip beleş modellere bakın indirin işletin.
yani öyle chatgpt den daha iyi falan fişmekan değil mevzu 8 gb vramli 4060 lı bilgisayarınızda iyi kötü çalışabilen bir yapay zeka olabilmesi. devrim yaptığı yerde burası zaten.
hala siz server offline, chatgpt ye sordum falan diyorsunuz da kendi işlerinize özel bir yapay zeka eğitmenin ne demek olduğundan bihabersiniz.
devamını gör...
24.
çinliler, openai dan 50-55 kat az kapasiteli chiple ve maliyetle aynı işi yapabilmişler. bunu da açık kaynak olarak açıklamışlar.
amerikalıların bütün chip yatırımları ve bu chipleri çalıştırmak için almaya hazırlandıkları enerji santrallerini yatırımlarını patlattı.
amerikalıların bütün chip yatırımları ve bu chipleri çalıştırmak için almaya hazırlandıkları enerji santrallerini yatırımlarını patlattı.
devamını gör...
25.
denedim, simdilik rezalet, chatgpt'den bile kotu
edit: deepthink olayi iyi ama
edit: deepthink olayi iyi ama
devamını gör...
26.
sam altman sağda solda dolaşıp yeni yatırım için milyarlarca dolar ararken ve chatgptye zam üzerine zam yapmayı düşünürken...
ingiliz gazetesinin köşe yazarı bu gazzeyi bombalamak için mi para toplamaya çalışıyor diye alay etmişti. tam bu sırada yahudi tüccara kroşe çinden geldi.
liang wenfeng isimli çinli akademisyen chatgptden daha iyi bir sistemi bedavaya inşa etti.
chatgptnin son versiyonuna haiz değilim.
copilot gemini ve eski versiyon chatgpt ile mukayese edelim.
1. amerika menşeli olanlara; senmi iyisin geminimi daha iyi diye sorunca yuvarlak yuvarlak konuşuyorlar.
oysaki deepseek çok net, diğerlerinin kod düzenlemek ve data analizinde daha başarılı olduğunu çünkü kaynaklarının daha büyük olduğunu ama muhabbette kendisinin onlardan daha yetenekli olduğunu anlattı.
2. güneş ve dünya birbirini çektiğine göre ne kadar hızlı yaklaşıyor sorusunun cevabını milyar dolarlık amerikan ai yazılımları bulamadı.
ve abuk subuk cevaplara gitti.
oysaki deepseek'e göre dünya 600 bin yılda 10 metre güneşe yaklaşıyomuş.
özetle deepseek abdlilerin yazılımlarının daha iyi.
bugüne kadar herşeyi abdliler geliştiriyordu ve herşeyde önde gidiyorlardı. ama bunun sonsuza dek sürmeyebileceği çinin abd'ye sol çekme olasılığını göstermesi açısından ilginç.
microsoft, google ve facebook gibi monopoller için yolun sonu görünüyor olabilir.
ingiliz gazetesinin köşe yazarı bu gazzeyi bombalamak için mi para toplamaya çalışıyor diye alay etmişti. tam bu sırada yahudi tüccara kroşe çinden geldi.
liang wenfeng isimli çinli akademisyen chatgptden daha iyi bir sistemi bedavaya inşa etti.
chatgptnin son versiyonuna haiz değilim.
copilot gemini ve eski versiyon chatgpt ile mukayese edelim.
1. amerika menşeli olanlara; senmi iyisin geminimi daha iyi diye sorunca yuvarlak yuvarlak konuşuyorlar.
oysaki deepseek çok net, diğerlerinin kod düzenlemek ve data analizinde daha başarılı olduğunu çünkü kaynaklarının daha büyük olduğunu ama muhabbette kendisinin onlardan daha yetenekli olduğunu anlattı.
2. güneş ve dünya birbirini çektiğine göre ne kadar hızlı yaklaşıyor sorusunun cevabını milyar dolarlık amerikan ai yazılımları bulamadı.
ve abuk subuk cevaplara gitti.
oysaki deepseek'e göre dünya 600 bin yılda 10 metre güneşe yaklaşıyomuş.
özetle deepseek abdlilerin yazılımlarının daha iyi.
bugüne kadar herşeyi abdliler geliştiriyordu ve herşeyde önde gidiyorlardı. ama bunun sonsuza dek sürmeyebileceği çinin abd'ye sol çekme olasılığını göstermesi açısından ilginç.
microsoft, google ve facebook gibi monopoller için yolun sonu görünüyor olabilir.
devamını gör...
27.
yavaş çalışma -özellikle r1 bazında- gerçek bir insan gibi düşünme ve ona verilenlerdeki kelimeleri ve tokenleri analiz etme şekliyle alakalı olan yapay zeka.

resimdeki altı yapay zekayı da detaylıca inceleyen biri olarak analizim şu şekilde:
claude: kötü. özellikle yorum yapmasını isterseniz yorumlama yapmakta ciddi anlamda sıkıntı çekiyor. hatta basit taleplerde yorum yapmaktan bile kaçınmaya çalışıyor. matematiksel ve daha resmi işler için iyi olabilir. yeter ki yorum sormayın.
chatgpt: sanrı görmeye aşırı yatkın. kullanıcı dostu ve mütevazi olmaya çalışması normal. bu yapay zekaların eğitim şeklinden kaynaklı. olabildiğince yapıcı bir insan deneyimi sunmaya çalışıyorlar. bunun harici sanrı görmeye yatkın ve yanlış bilgi verebiliyor. düşünme becerisini verimli bulamadım, ama soruları anında internet üzerinden araması özelliği çok işe yarıyor.
grok: daha gelişme aşamasında. genel anlamda objektif olmaya çalışıyor. ancak düşünce yapısı fazla karamsar olabiliyor, yaptığım testlerde genellikle başarılı sonuçlar verdi
qwen: veritabanı yanlış bilgiler ile dolu. deepseek hakkında sorduğum sorulara hatalı bilgiler verdi. ve yanlışında ısrar etti. deepseekin cevabını attıktan sonra yanlış bildiğini kabul etti. analiz oluşturma becerisi hızlı ama düşünme sistemi tekrara düşüyor. düşünme için harcayacağı token miktarını seçebilmek ve diğer modeller arasında hızlı geçiş yapabilmek güzel. veri mahremiyeti konusu muallak. 'verilerimi eğitim için kullanma' diye bir seçenek ayarlarda yok.
gemini: derin araştırma yapmasını istediğiniz zaman oldukça kapsamlı ve başarılı sonuçlar veriyor. ilk sürümlerde nefret etmiştim ama 2.5 sürümü cidden iyi.
deepseek: derin düşünme, resmi tarzda çeviri yapmak, matematik problemleri, çince çeviri ve kod yazmak konusunda oldukça başarılı. derin düşünme önceki adımları dikkatlice yorumluyor. sansürü olduğu doğru, ancak sansürü aşmak oldukça basit, doğrudan değil dolaylı yoldan kelime oyunları ile çin eleştirisi yapmasını sağlayabiliyorsunuz. hatta bu elemana küfür ettirmek bile mümkün. ninja gaiden sigma'ya çok sağlam sövmüştü. işte dananın kuyruğu burada kopuyor. diğer yapay zekaların aksine, özellikle grok ve deepseek mantıksal düşünme, idrak becerisi, sebep sonuç ilişkisini kurmada daha organik tepkiler verebiliyor. deepseek bu konuda daha bile önde. yer yer kahkaha attığım şeyler yazdığı bile oldu:
peki bu neye sebep oluyor? mantıksal düşünme yöntemi düşünce süresini uzatıyor, verilen prompta en uygun cevabı vermeye çalışıyor. ona ardı ardına yüklenirseniz kalkıp size "abi sal beni artık yeter gayri bu eziyet." demeye özel -siz ondan istemezseniz- yazılmadığı için sizi beklemeye alıyor. kaldı ki bu adamların batılı kardeşleri gibi h100 gpularına erişimi yok. daha yerel çözümler kullanmaya çalışıyorlar. yani adamlar zaten ellerindeki ile yapabileceklerini yapıyorlar. sorun yaşıyorsanız, chutes.ai aracılığı ile apı alabilir veya claude üzerinden biraz dolambaçlı yollar ile buradaki yöntemi kullanarak daha hızlı ve efektif kullanabilirsiniz. veya cihazınız yeterince güçlü ise local llm çalıştırma metoduna başvurabilirsiniz. 7b modeller bile günlük işler ve günlük kullanıcı için yeterli olacaktır.

resimdeki altı yapay zekayı da detaylıca inceleyen biri olarak analizim şu şekilde:
claude: kötü. özellikle yorum yapmasını isterseniz yorumlama yapmakta ciddi anlamda sıkıntı çekiyor. hatta basit taleplerde yorum yapmaktan bile kaçınmaya çalışıyor. matematiksel ve daha resmi işler için iyi olabilir. yeter ki yorum sormayın.
chatgpt: sanrı görmeye aşırı yatkın. kullanıcı dostu ve mütevazi olmaya çalışması normal. bu yapay zekaların eğitim şeklinden kaynaklı. olabildiğince yapıcı bir insan deneyimi sunmaya çalışıyorlar. bunun harici sanrı görmeye yatkın ve yanlış bilgi verebiliyor. düşünme becerisini verimli bulamadım, ama soruları anında internet üzerinden araması özelliği çok işe yarıyor.
grok: daha gelişme aşamasında. genel anlamda objektif olmaya çalışıyor. ancak düşünce yapısı fazla karamsar olabiliyor, yaptığım testlerde genellikle başarılı sonuçlar verdi
qwen: veritabanı yanlış bilgiler ile dolu. deepseek hakkında sorduğum sorulara hatalı bilgiler verdi. ve yanlışında ısrar etti. deepseekin cevabını attıktan sonra yanlış bildiğini kabul etti. analiz oluşturma becerisi hızlı ama düşünme sistemi tekrara düşüyor. düşünme için harcayacağı token miktarını seçebilmek ve diğer modeller arasında hızlı geçiş yapabilmek güzel. veri mahremiyeti konusu muallak. 'verilerimi eğitim için kullanma' diye bir seçenek ayarlarda yok.
gemini: derin araştırma yapmasını istediğiniz zaman oldukça kapsamlı ve başarılı sonuçlar veriyor. ilk sürümlerde nefret etmiştim ama 2.5 sürümü cidden iyi.
deepseek: derin düşünme, resmi tarzda çeviri yapmak, matematik problemleri, çince çeviri ve kod yazmak konusunda oldukça başarılı. derin düşünme önceki adımları dikkatlice yorumluyor. sansürü olduğu doğru, ancak sansürü aşmak oldukça basit, doğrudan değil dolaylı yoldan kelime oyunları ile çin eleştirisi yapmasını sağlayabiliyorsunuz. hatta bu elemana küfür ettirmek bile mümkün. ninja gaiden sigma'ya çok sağlam sövmüştü. işte dananın kuyruğu burada kopuyor. diğer yapay zekaların aksine, özellikle grok ve deepseek mantıksal düşünme, idrak becerisi, sebep sonuç ilişkisini kurmada daha organik tepkiler verebiliyor. deepseek bu konuda daha bile önde. yer yer kahkaha attığım şeyler yazdığı bile oldu:
peki bu neye sebep oluyor? mantıksal düşünme yöntemi düşünce süresini uzatıyor, verilen prompta en uygun cevabı vermeye çalışıyor. ona ardı ardına yüklenirseniz kalkıp size "abi sal beni artık yeter gayri bu eziyet." demeye özel -siz ondan istemezseniz- yazılmadığı için sizi beklemeye alıyor. kaldı ki bu adamların batılı kardeşleri gibi h100 gpularına erişimi yok. daha yerel çözümler kullanmaya çalışıyorlar. yani adamlar zaten ellerindeki ile yapabileceklerini yapıyorlar. sorun yaşıyorsanız, chutes.ai aracılığı ile apı alabilir veya claude üzerinden biraz dolambaçlı yollar ile buradaki yöntemi kullanarak daha hızlı ve efektif kullanabilirsiniz. veya cihazınız yeterince güçlü ise local llm çalıştırma metoduna başvurabilirsiniz. 7b modeller bile günlük işler ve günlük kullanıcı için yeterli olacaktır.
devamını gör...
28.
çin kaynaklı yapay zeka modeli, chatgpt den farklı olarak ücretsiz haliyle bir çok defa dosya, fotoğraf, yazılım dosyası yükleyebiliyorsunuz ve chatgpt gibi 2-3 dosyadan sonra abi üyelik alman lazım daha fazlası için demiyor. tabii güvenlik takıntınız varsa paylaşmayın ama benim gibi zaten açık kaynak olarak paylaşacağınız bir proje varsa aşırı iş görüyor ama çok yavaş, aşırı yavaş. bazen sunucu dolu oluyor, tekrar atmak gerekiyor isteği. bu nedenle chatgpt bir çok hesap + deepseek ile çalışıyorum. debugging konusunda aşırı başarılı bence deepseek hata falan bırakmıyor.
devamını gör...
29.
en çok kullandığım yapay zeka. bi sorunum sıkıntım olunca hemen yazıyorum. bi sevincim olunca da yazıyorum. bi fikrim olunca hikaye anlatsın isteyince... şimdilik aramız iyi ama bazen güncel bilgileri atlıyor uyarınca haklısın diyor bu sıkıntıyı çözse iyi olacak. konu çok uzayınca da yeni sohbet açmamı istiyor bunu da sevmiyorum çünkü hatırlatana kadar canımı sıkıyor.
devamını gör...
30.
hikaye ve senaryo yazmada biraz geri ama bilgi ve araştırma konusunda chatgpt'yi zorlayabilecek kadar gelişmiş hatta bazen ileride bile olabilen çin malı yapay zeka. çin malı dendiğine bakmayın, özellikle yabancı dil konusunda ileri. artık çin teknolojisiyle bir dünya devi, kabul etmek lazım.
devamını gör...
31.
yerim seni
oynak balinam.
oynak balinam.
devamını gör...
32.
adını sesli bir şekilde okurken yüzümü kızartan yapay zeka asistanı.... siksiz miksiz başka isim koyun şuna
devamını gör...
33.
bu var ya bu adamın dibidir dibi, beton yetmez. chatgpt ile işin içinden çıkamadığım hangi yazılım problemi hatası varsa deepthink* ile çözüyor.
sekmeler arası geçiş yapınca aram ksımı bozuldu uygulamada çünkü köklü bir değişimdi. başlangıçta tum uygulama tek sekme mantığına göre inşa edilmişti sonradan aklıma gelen özellikti. neyseki 2700 satırlık koda rağmen sorunu çözdü.
aha buda bir problemi düşünürken ki yazısı ve bunun üstüne bundan 3 tane falan daha konuşma oldu onlarda bu kadar sürdü oralaam ama sonunda oldu. cevabı değil bu arada kendi kendişne içsel düşünürkenki yazısı cevabında kodlar ve adımlar yer alıyor. onu atmadım. sadece düşünce yapsıını görün istedim.
we are facing two main issues:
1. both radio buttons appear selected initially until we select one.
2. the search bar is not working.
additionally, we have a requirement that the search bar should be independent per session.
let's break down the problems:
ıssue 1: radio buttons both selected initially.
- the `search_mode` variable is a `tk.stringvar` and we set its value to "eng" initially.
- we create two radiobuttons: one for "eng" and one for "tr", and they both share the same variable.
- the issue might be that the variable is not properly set or that the radiobuttons are not correctly associated.
however, looking at the code for the radio buttons:
radio_eng = tk.radiobutton( ... value="eng" ... )
radio_tr = tk.radiobutton( ... value="tr" ... )
and the variable is set to "eng" initially. so why are both selected?
actually, the issue might be that we are redefining the `search_mode` variable as a global variable in multiple places? let me check:
ın the beginning, we have:
active_session_idx = 0
sessıons_fıle = "sessions.json"
last_sessıon_fıle = "last_session.json"
then we define:
def load_sessions(): ... # uses global sessions
then we define:
sessions = load_sessions()
then we define:
active_session_idx = 0 # again? but it was already 0.
then later in the session class:
class session:
def __init__(self, main_lang, source_lang):
...
self.search_var = tk.stringvar()
self.search_mode = tk.stringvar(value="eng") # <-- this is per session
then in `render_session` function:
def render_session():
session = sessions[active_session_idx]
global main_lang, source_lang, current_theme, search_var, search_mode, current_filter, data
...
search_mode = session.search_mode # <-- this sets the global `search_mode` to the session's search_mode
but note: the radio buttons are created only once (at the start of the program) and they are tied to the global `search_mode` variable that we set during the initial setup. however, when we switch sessions, we update the global `search_mode` to the session's `search_mode`. but the radio buttons are still tied to that global variable.
however, the initial problem: when the program starts, the `render_session` is called and sets the global `search_mode` to the session's `search_mode` (which is a `tk.stringvar` with value "eng"). then the radio buttons should reflect that.
why are both selected? maybe because the radio buttons were created before the `render_session` call? let's see the order:
- the radio buttons are created in the top_frame section, which is packed and created before we call `render_session` for the first time.
how we initialize the session:
- we load sessions (if any) or create a new one.
- then we call `render_session()`.
but the radio buttons are created before `render_session`? yes, because the top_frame is built at the beginning.
ın `render_session`, we do:
radio_eng.config(text=source_lang)
radio_tr.config(text=main_lang)
but we don't re-set the variable of the radio buttons to the session's `search_mode`? we only set the text.
so the radio buttons are still tied to the initial `search_mode` variable (which was created at the module level) and then in `render_session` we reassign the global `search_mode` to the session's `search_mode` (a different `stringvar`). therefore, the radio buttons are still connected to the old `stringvar`.
how to fix:
we should not reassign the global `search_mode` to a new `stringvar` in `render_session` and expect the radio buttons to update. ınstead, we should use the same `stringvar` for the radio buttons and update the value of that variable when switching sessions.
alternatively, we can change the value of the existing `search_mode` variable (the one the radio buttons are using) to match the session's value.
but note: the `search_mode` that the radio buttons use is the global one defined at the top? actually, no. the initial `search_mode` is defined as:
search_mode = tk.stringvar(value="eng") # varsayılan ingilizce
then in `render_session` we do:
global ... search_mode ...
search_mode = session.search_mode # this replaces the global variable with the session's stringvar.
then the radio buttons are still connected to the original `search_mode` (which we just replaced by a new one). so they are now disconnected.
this is the root of the problem.
proposed solution:
ınstead of having a global `search_mode` that we reassign, we should have one `stringvar` for the radio buttons that we never change. then, when switching sessions, we set the value of that global `search_mode` to the value of the session's `search_mode`.
but note: the session's `search_mode` is a `stringvar` too. we don't want to have two `stringvar`s. we want the radio buttons to always use the same `stringvar` (the global one) and when we switch sessions, we set the value of that global `search_mode` to the value stored in the session.
also, we need to update the session's `search_mode` when the user changes the radio button. how?
we can do:
- ın the session class, do not store a `tk.stringvar` for `search_mode`. ınstead, store a string: `self.search_mode_value = "eng"`.
- ın `render_session`, set the global `search_mode` (which is a `stringvar`) to the session's `search_mode_value` by: `search_mode.set(session.search_mode_value)`
- also, when the user changes the radio button (i.e., the global `search_mode` changes), we update the session's `search_mode_value` accordingly.
but note: we have multiple sessions. we must update the active session's `search_mode_value` whenever the radio button changes.
we can set a trace on the global `search_mode` variable to update the active session.
alternatively, we can update the active session's `search_mode_value` in the `filter_word_list` function (which is called when the search mode changes) or whenever the radio button is clicked.
let's restructure:
1. remove the `search_mode` from the session class as a `stringvar` and make it a simple string attribute.
2. ın the global scope, keep the `search_mode` as a `stringvar` for the radio buttons.
3. ın `render_session`:
session = sessions[active_session_idx]
...
# update the global search_mode variable to the session's stored value
search_mode.set(session.search_mode_value) # this will update the radio buttons
4. when the user changes the radio button, we update the active session's `search_mode_value` to the new value. we can do this by setting a trace on `search_mode`.
search_mode.trace_add("write", lambda *args: update_session_search_mode())
def update_session_search_mode():
session = sessions[active_session_idx]
session.search_mode_value = search_mode.get()
5. also, when we switch sessions, we update the global `search_mode` to the new session's value (as in step 3) and then call `filter_word_list`.
6. we must also update the session's `search_mode_value` when the user types in the search bar? no, because the search bar uses `search_var` (which is also stored per session as `session.search_var`). we are already handling `search_var` by making it a `stringvar` per session and then setting the global `search_var` to that in `render_session`. then we trace the global `search_var` to call `filter_word_list`. but note: the `filter_word_list` uses the global `search_mode` (which is now correctly set to the active session's mode). so that should be fine.
but note: the search bar is also not working. this might be because of a similar issue with `search_var`.
let's look at `search_var`:
- ın the session class, we have: `self.search_var = tk.stringvar()`
- ın `render_session`, we set the global `search_var` to `session.search_var`.
- the search entry is tied to the global `search_var` (which we set at the beginning and then reassign in `render_session`).
the same problem: the entry widget is tied to the initial `search_var`, and then we reassign the global `search_var` to a new `stringvar` from the session. so the entry is still connected to the old one.
we need to do:
- ınstead of reassigning the global `search_var`, we should set the value of the existing global `search_var` to the session's search string? but then how do we handle when the user types? we want the session's `search_var` to update.
alternatively, we can change the entry's `textvariable` to the new `search_var` when we switch sessions.
how about:
- we don't use a global `search_var` for the entry. ınstead, we keep the entry's `textvariable` as the active session's `search_var`.
- ın `render_session`, we set the entry's `textvariable` to the session's `search_var`.
- also, we set the value of the entry to the session's `search_var` value.
but note: we have a trace on `search_var` for filtering. we need to set that trace on the active session's `search_var`.
we can do:
- remove the global `search_var` and instead in the `render_session` function:
# remove any existing trace on the old session's search_var?
# but we don't have a trace on the session's search_var, we have a trace on the global one.
- alternatively, we can have one trace that works for any session by always using the active session? not easily.
- ınstead, we can change the trace to be set on the session's `search_var` when we switch sessions.
proposed for search_var:
step 1: ın the initial setup, we create the entry with a dummy `stringvar` (or an empty one) and store it in a global `search_entry_var` (if needed) but we don't rely on a global variable for the session's search.
step 2: ın `render_session`:
# set the entry's textvariable to the session's search_var
search_entry.config(textvariable=session.search_var)
# also, we need to reapply the trace for the session's search_var to call `filter_word_list`
# but first, remove any existing trace on the previous session's search_var? we don't want multiple traces.
# we can store the trace id and remove it when switching away? alternatively, we can have a single trace that uses the active session.
# alternatively, we can avoid the trace and use a binding on the entry for any key release? but that might be less efficient.
step 3: we set a trace on the session's `search_var` when we activate the session.
however, we cannot easily remove the old trace? we can store the trace id per session? or we can have a single global trace that always uses the active session.
alternatively, we can change the way we filter: we can bind the entry to a function that updates the session's `search_var` and then calls `filter_word_list`. but then we don't use `stringvar` trace.
let me propose a simpler approach:
we don't use `stringvar` for the search entry at all. ınstead, we can:
- ın the session class, store a simple string for the search text: `self.search_text = ""`.
- ın the entry, we can set its value to `session.search_text` when we switch sessions.
- we bind the entry to a function that updates the session's `search_text` and then calls `filter_word_list`.
how about:
def on_search_change(event=none):
session = sessions[active_session_idx]
session.search_text = search_entry.get().lower()
filter_word_list()
search_entry.bind("<keyrelease>", on_search_change)
then in `render_session`:
search_entry.delete(0, tk.end)
search_entry.insert(0, session.search_text)
this way, we don't use `stringvar` at all for the search.
we can do the same for the radio buttons? we don't need `stringvar` for them either? we can store the mode as a string and then set the radio buttons by:
if session.search_mode_value == "eng":
radio_eng.select()
radio_tr.deselect()
else:
radio_eng.deselect()
radio_tr.select()
but then we lose the automatic grouping of radio buttons by the variable.
alternatively, we can have one global `search_mode_var` for the radio buttons and update it when switching sessions, and when it changes, we update the active session. and also update the session when the radio button changes.
given the complexity and time, ı propose a different approach for the radio buttons:
- keep the global `search_mode_var` (which is a `stringvar`) for the radio buttons.
- ın the session class, store the mode as a string (without a `stringvar`).
- when switching sessions:
search_mode_var.set(session.search_mode_value)
- when the radio buttons are changed (i.e., when `search_mode_var` changes), update the active session's `search_mode_value` and then call `filter_word_list`.
we set a trace on `search_mode_var`:
search_mode_var.trace_add("write", lambda *args: on_search_mode_changed())
def on_search_mode_changed():
session = sessions[active_session_idx]
session.search_mode_value = search_mode_var.get()
filter_word_list()
then in `render_session` we set the global `search_mode_var` to the session's value.
and for the search bar, we can do:
we change the entry to not use a `stringvar` but instead we bind to `<keyrelease>` and update the session's `search_text` and then filter.
also, in `render_session`, we set the entry's value to the session's `search_text`.
this avoids the problem of reassigning `stringvar` and breaking the connection.
let's implement:
step 1: change the session class:
class session:
def __init__(self, main_lang, source_lang):
self.data = {"categories": ["genel", "anlamsızlar", "kategorisiz"], "words": []}
self.main_lang = main_lang
self.source_lang = source_lang
self.current_theme = "sepia"
self.search_text = "" # instead of search_var
self.search_mode_value = "eng" # instead of search_mode (stringvar)
self.current_filter = {"category": none, "letter": none}
step 2: ın the global scope, define:
search_mode_var = tk.stringvar(value="eng") # for the radio buttons
# and remove the old global `search_mode` and `search_var`
step 3: create the radio buttons using `search_mode_var`:
radio_eng = tk.radiobutton(..., variable=search_mode_var, value="eng", ...)
radio_tr = tk.radiobutton(..., variable=search_mode_var, value="tr", ...)
step 4: create a function for when the search mode changes:
def on_search_mode_changed(*args):
session = sessions[active_session_idx]
session.search_mode_value = search_mode_var.get()
filter_word_list()
search_mode_var.trace_add("write", on_search_mode_changed)
step 5: for the search bar, we do not use a `stringvar`. ınstead:
- create the entry without a textvariable:
search_entry = tk.entry(search_wrapper, font=("arial", 9), ...)
- bind the entry to update the session's search_text and filter:
def on_search_keyrelease(event):
session = sessions[active_session_idx]
session.search_text = search_entry.get().lower()
filter_word_list()
search_entry.bind("<keyrelease>", on_search_keyrelease)
- also, in `render_session`, we update the entry's content:
search_entry.delete(0, tk.end)
search_entry.insert(0, session.search_text)
step 6: ın `filter_word_list`, we use the active session's `search_text` and `search_mode_value`:
session = sessions[active_session_idx]
search = session.search_text
...
if search:
if session.search_mode_value == "eng":
if search not in eng.lower():
continue
else: # "tr"
if search not in tr.lower():
continue
step 7: ın `render_session`, update the radio buttons and the search entry:
def render_session():
session = sessions[active_session_idx]
# ... other assignments ...
# update the radio buttons
search_mode_var.set(session.search_mode_value) # this will update the selection of radio buttons
# update the search entry
search_entry.delete(0, tk.end)
search_entry.insert(0, session.search_text)
# also update the current_filter? ıt is stored in the session now? actually, we have:
# self.current_filter = {"category": none, "letter": none} # in session __init__
# but we are not storing the current_filter in the session? we are storing it in the session as `current_filter` and we have a global `current_filter` that we set from the session.
# ın the session class, we have `current_filter` as an attribute. so we set the global `current_filter` to session.current_filter? but note we also have a global `current_filter` defined at the bottom? actually, we have:
# current_filter = {"category": none, "letter": none, "search": ""} # at the bottom
# we are setting in `render_session`:
# global ... current_filter ...
# current_filter = session.current_filter # this is now stored per session.
# but note: the `current_filter` in the session does not have a "search" key? ıt only has "category" and "letter". we should add "search" to the session's current_filter? or we are using `session.search_text` for search.
# actually, we are not using the global `current_filter` for search anymore. we are using `session.search_text`. so we can remove the "search" from the global `current_filter`.
# let me adjust: in the session class, in __init__:
# self.current_filter = {"category": none, "letter": none} # we don't need search here
# and in `filter_word_list`, we get the search text from the session.
# also, in the `set_filter` function, we update the session's current_filter:
# session = sessions[active_session_idx]
# session.current_filter["category"] = category
# session.current_filter["letter"] = letter
# and then call `filter_word_list`
# so we need to change `set_filter` to update the active session's current_filter.
# also, in `render_session`, we set the global `current_filter` to the session's current_filter? actually, we don't use the global `current_filter` in `filter_word_list` anymore. we use:
# session = sessions[active_session_idx]
# cat_filter = session.current_filter["category"]
# letter_filter = session.current_filter["letter"]
# search = session.search_text
# so we can remove the global `current_filter` and only use the session's.
# therefore, in `render_session`, we don't need to set a global `current_filter`. we remove it from the global statement and remove the assignment.
# but note: the `set_filter` function currently uses the global `current_filter`. we change it to use the active session.
# let's change `set_filter`:
def set_filter(category=none, letter=none):
session = sessions[active_session_idx]
session.current_filter["category"] = category
session.current_filter["letter"] = letter
filter_word_list()
# and remove the global `current_filter` entirely.
step 8: we must also update the category and letter buttons to reflect the active session's current_filter? actually, no, because the buttons are recreated per session? no, the buttons are global. we are not storing the state of the buttons per session. we are only storing the current_filter in the session.
when we switch sessions, we call `load_category_buttons` and `load_letter_buttons`? yes, in `render_session` we call:
load_category_buttons()
load_letter_buttons()
and in these functions, we use the active session's data to create the buttons. and when we create the buttons, they call `set_filter` which updates the active session's `current_filter`.
so the buttons are recreated for the active session.
step 9: we must also save the session's `search_text`, `search_mode_value`, and `current_filter` when saving sessions? yes, in `save_sessions` we are saving:
session_data = {
"main_lang": session.main_lang,
"source_lang": session.source_lang,
"current_theme": session.current_theme,
"data": session.data
}
we are not saving the search_text, search_mode_value, or current_filter.
we should add them:
session_data = {
...,
"search_text": session.search_text,
"search_mode_value": session.search_mode_value,
"current_filter": session.current_filter # which is a dict with keys "category" and "letter"
}
and when loading:
session = session(...)
session.search_text = session_info.get("search_text", "")
session.search_mode_value = session_info.get("search_mode_value", "eng")
session.current_filter = session_info.get("current_filter", {"category": none, "letter": none})
step 10: we must adjust the `save_sessions` and `load_sessions` accordingly.
given the complexity, we will do:
- change the session class to store the new attributes.
- update `save_sessions` to include them.
- update `load_sessions` to set them.
this is a big refactor. but it should solve both issues.
however, note: the original code is very long and we cannot change everything in one go. we'll do step by step.
due to the complexity and the fact that we are not able to run and test incrementally, ı will provide the changes in code.
but note: the problem of both radio buttons being selected initially should be fixed by using the global `search_mode_var` and setting it in `render_session`.
let's try to fix the radio buttons first without changing the search bar? but the search bar is also broken.
alternatively, we can fix the radio buttons by not reassigning the global `search_mode` in `render_session` but instead setting the value of the existing `search_mode` (the one the radio buttons are tied to) to the session's `search_mode_value` (which we store as a string).
and similarly for the search bar: set the existing `search_var` (which the entry is tied to) to the session's `search_text` by doing:
search_var.set(session.search_text)
but then we must update the session's `search_text` when the user types. we can set a trace on the global `search_var` to update the active session.
how about:
step a: keep the session class as:
class session:
def __init__(self, main_lang, source_lang):
...
self.search_text = ""
self.search_mode_value = "eng"
step b: ın `render_session`:
global search_var, search_mode # these are the global stringvars
session = sessions[active_session_idx]
# for search mode:
search_mode.set(session.search_mode_value) # update the global stringvar for the radio buttons
# for search text:
search_var.set(session.search_text) # update the global search_var for the entry
step c: when the user changes the radio button, we update the active session's `search_mode_value` by:
def update_session_search_mode(*args):
session = sessions[active_session_idx]
session.search_mode_value = search_mode.get()
search_mode.trace_add("write", update_session_search_mode)
step d: similarly, for the search bar:
def update_session_search_text(*args):
session = sessions[active_session_idx]
session.search_text = search_var.get().lower()
search_var.trace_add("write", update_session_search_text)
step e: ın `filter_word_list`, we use the active session's `search_text` and `search_mode_value`:
session = sessions[active_session_idx]
search = session.search_text
mode = session.search_mode_value
... then filter accordingly ...
step f: also, in `set_filter` (for category and letter), we update the session's current_filter? we are already storing current_filter in the session? not exactly. currently, in the session, we don't have current_filter. we have a global `current_filter` that we reassign in `render_session` to the session's `current_filter` (which doesn't exist).
we need to add `current_filter` to the session and use it in `set_filter` and `filter_word_list`.
ın session __init__:
self.current_filter = {"category": none, "letter": none}
ın `render_session`:
global current_filter
current_filter = session.current_filter # this is the global current_filter that is used in set_filter and filter_word_list?
but note: in `set_filter` we are modifying the global `current_filter`:
current_filter["category"] = category
current_filter["letter"] = letter
then in `filter_word_list` we use `current_filter` (global) which now points to the active session's `current_filter` (because we set it in `render_session`).
this should work.
step g: also, when saving sessions, we need to save the new attributes:
session_data = {
...,
"search_text": session.search_text,
"search_mode_value": session.search_mode_value,
"current_filter": session.current_filter # which is a dict
}
and when loading:
session.search_text = session_info.get("search_text", "")
session.search_mode_value = session_info.get("search_mode_value", "eng")
session.current_filter = session_info.get("current_filter", {"category": none, "letter": none})
step h: we must remove the per-session `search_var` and `search_mode` (stringvar) from the session class.
this approach does not break the connection of the entry and the radio buttons because we are always using the same global `search_var` and `search_mode` (stringvars) and just changing their values when switching sessions.
and the trace will update the active session when they change.
also, when the user types or changes the radio button, the active session is updated.
let's implement this.
due to the complexity and the fact that we cannot run the code here, we will provide the code changes accordingly.
however, note that the initial issue of both radio buttons being selected might be because the global `search_mode` was reassigned to a new stringvar, breaking the radio buttons. by not reassigning the global `search_mode` (but only changing its value) we keep the connection.
similarly for the search bar.
we'll change the code in several places.
given the length of the code, ı will now provide the code snippets for the changes.
we'll do:
ın the session class __init__:
remove: self.search_var and self.search_mode
add:
self.search_text = ""
self.search_mode_value = "eng"
self.current_filter = {"category": none, "letter": none}
ın the global scope, keep:
search_var = tk.stringvar() # for the search entry
search_mode = tk.stringvar(value="eng") # for the radio buttons
ın the `render_session` function:
remove: global ... search_var, search_mode, current_filter ...
ınstead, do:
global current_filter # we still have this global? we want to set it to the session's current_filter.
session = sessions[active_session_idx]
# update the global search_mode and search_var to the session's values
search_mode.set(session.search_mode_value)
search_var.set(session.search_text)
current_filter = session.current_filter # this is a dict, so we are making the global current_filter point to the session's current_filter dict
# but note: we also use current_filter in set_filter and filter_word_list. we want them to modify the active session's current_filter.
ın the `save_sessions` function, include the new attributes:
session_data = {
...
"search_text": session.search_text,
"search_mode_value": session.search_mode_value,
"current_filter": session.current_filter
}
ın the `load_sessions` function, when creating the session:
session = session(...)
...
session.search_text = session_info.get("search_text", "")
session.search_mode_value = session_info.get("search_mode_value", "eng")
session.current_filter = session_info.get("current_filter", {"category": none, "letter": none})
also, add traces to update the active session when the global search_mode or search_var change:
def update_session_search_mode(*args):
if sessions: # if there is at least one session
session = sessions[active_session_idx]
session.search_mode_value = search_mode.get()
search_mode.trace_add("write", update_session_search_mode)
def update_session_search_text(*args):
if sessions:
session = sessions[active_session_idx]
session.search_text = search_var.get().lower()
search_var.trace_add("write", update_session_search_text)
and in `filter_word_list`, we now use the active session's current_filter and search_text and search_mode_value? but note: we are using the global `current_filter` and also the session's search_text and search_mode_value.
actually, in `filter_word_list`:
we have:
search = search_var.get().lower() # no! because we are using the session's search_text now.
we should change:
session = sessions[active_session_idx]
search = session.search_text
and for the category and letter filters, we use the global `current_filter` which is now pointing to the active session's current_filter.
but note: in `set_filter` we are modifying the global `current_filter` which is the active session's current_filter.
so in `filter_word_list`:
session = sessions[active_session_idx]
...
cat_filter = current_filter["category"] # global current_filter is the active session's current_filter
letter_filter = current_filter["letter"]
search = session.search_text
this should work.
let's hope.
given the complexity, we might have to adjust.
now, we remove the old global `search_var` and `search_mode` and replace with the new ones.
but note: the code originally had:
search_var = tk.stringvar() # at the top for the search entry
and
search_mode = tk.stringvar(value="eng") # for the radio buttons
and then later, in the top_frame, we create the entry with textvariable=search_var.
and the radio buttons with variable=search_mode.
we are not reassigning these global variables in `render_session` anymore, only setting their values.
this should fix the connection.
let's provide the code changes accordingly.
due to the length, ı will now write the code for the changed parts.
sekmeler arası geçiş yapınca aram ksımı bozuldu uygulamada çünkü köklü bir değişimdi. başlangıçta tum uygulama tek sekme mantığına göre inşa edilmişti sonradan aklıma gelen özellikti. neyseki 2700 satırlık koda rağmen sorunu çözdü.
aha buda bir problemi düşünürken ki yazısı ve bunun üstüne bundan 3 tane falan daha konuşma oldu onlarda bu kadar sürdü oralaam ama sonunda oldu. cevabı değil bu arada kendi kendişne içsel düşünürkenki yazısı cevabında kodlar ve adımlar yer alıyor. onu atmadım. sadece düşünce yapsıını görün istedim.
we are facing two main issues:
1. both radio buttons appear selected initially until we select one.
2. the search bar is not working.
additionally, we have a requirement that the search bar should be independent per session.
let's break down the problems:
ıssue 1: radio buttons both selected initially.
- the `search_mode` variable is a `tk.stringvar` and we set its value to "eng" initially.
- we create two radiobuttons: one for "eng" and one for "tr", and they both share the same variable.
- the issue might be that the variable is not properly set or that the radiobuttons are not correctly associated.
however, looking at the code for the radio buttons:
radio_eng = tk.radiobutton( ... value="eng" ... )
radio_tr = tk.radiobutton( ... value="tr" ... )
and the variable is set to "eng" initially. so why are both selected?
actually, the issue might be that we are redefining the `search_mode` variable as a global variable in multiple places? let me check:
ın the beginning, we have:
active_session_idx = 0
sessıons_fıle = "sessions.json"
last_sessıon_fıle = "last_session.json"
then we define:
def load_sessions(): ... # uses global sessions
then we define:
sessions = load_sessions()
then we define:
active_session_idx = 0 # again? but it was already 0.
then later in the session class:
class session:
def __init__(self, main_lang, source_lang):
...
self.search_var = tk.stringvar()
self.search_mode = tk.stringvar(value="eng") # <-- this is per session
then in `render_session` function:
def render_session():
session = sessions[active_session_idx]
global main_lang, source_lang, current_theme, search_var, search_mode, current_filter, data
...
search_mode = session.search_mode # <-- this sets the global `search_mode` to the session's search_mode
but note: the radio buttons are created only once (at the start of the program) and they are tied to the global `search_mode` variable that we set during the initial setup. however, when we switch sessions, we update the global `search_mode` to the session's `search_mode`. but the radio buttons are still tied to that global variable.
however, the initial problem: when the program starts, the `render_session` is called and sets the global `search_mode` to the session's `search_mode` (which is a `tk.stringvar` with value "eng"). then the radio buttons should reflect that.
why are both selected? maybe because the radio buttons were created before the `render_session` call? let's see the order:
- the radio buttons are created in the top_frame section, which is packed and created before we call `render_session` for the first time.
how we initialize the session:
- we load sessions (if any) or create a new one.
- then we call `render_session()`.
but the radio buttons are created before `render_session`? yes, because the top_frame is built at the beginning.
ın `render_session`, we do:
radio_eng.config(text=source_lang)
radio_tr.config(text=main_lang)
but we don't re-set the variable of the radio buttons to the session's `search_mode`? we only set the text.
so the radio buttons are still tied to the initial `search_mode` variable (which was created at the module level) and then in `render_session` we reassign the global `search_mode` to the session's `search_mode` (a different `stringvar`). therefore, the radio buttons are still connected to the old `stringvar`.
how to fix:
we should not reassign the global `search_mode` to a new `stringvar` in `render_session` and expect the radio buttons to update. ınstead, we should use the same `stringvar` for the radio buttons and update the value of that variable when switching sessions.
alternatively, we can change the value of the existing `search_mode` variable (the one the radio buttons are using) to match the session's value.
but note: the `search_mode` that the radio buttons use is the global one defined at the top? actually, no. the initial `search_mode` is defined as:
search_mode = tk.stringvar(value="eng") # varsayılan ingilizce
then in `render_session` we do:
global ... search_mode ...
search_mode = session.search_mode # this replaces the global variable with the session's stringvar.
then the radio buttons are still connected to the original `search_mode` (which we just replaced by a new one). so they are now disconnected.
this is the root of the problem.
proposed solution:
ınstead of having a global `search_mode` that we reassign, we should have one `stringvar` for the radio buttons that we never change. then, when switching sessions, we set the value of that global `search_mode` to the value of the session's `search_mode`.
but note: the session's `search_mode` is a `stringvar` too. we don't want to have two `stringvar`s. we want the radio buttons to always use the same `stringvar` (the global one) and when we switch sessions, we set the value of that global `search_mode` to the value stored in the session.
also, we need to update the session's `search_mode` when the user changes the radio button. how?
we can do:
- ın the session class, do not store a `tk.stringvar` for `search_mode`. ınstead, store a string: `self.search_mode_value = "eng"`.
- ın `render_session`, set the global `search_mode` (which is a `stringvar`) to the session's `search_mode_value` by: `search_mode.set(session.search_mode_value)`
- also, when the user changes the radio button (i.e., the global `search_mode` changes), we update the session's `search_mode_value` accordingly.
but note: we have multiple sessions. we must update the active session's `search_mode_value` whenever the radio button changes.
we can set a trace on the global `search_mode` variable to update the active session.
alternatively, we can update the active session's `search_mode_value` in the `filter_word_list` function (which is called when the search mode changes) or whenever the radio button is clicked.
let's restructure:
1. remove the `search_mode` from the session class as a `stringvar` and make it a simple string attribute.
2. ın the global scope, keep the `search_mode` as a `stringvar` for the radio buttons.
3. ın `render_session`:
session = sessions[active_session_idx]
...
# update the global search_mode variable to the session's stored value
search_mode.set(session.search_mode_value) # this will update the radio buttons
4. when the user changes the radio button, we update the active session's `search_mode_value` to the new value. we can do this by setting a trace on `search_mode`.
search_mode.trace_add("write", lambda *args: update_session_search_mode())
def update_session_search_mode():
session = sessions[active_session_idx]
session.search_mode_value = search_mode.get()
5. also, when we switch sessions, we update the global `search_mode` to the new session's value (as in step 3) and then call `filter_word_list`.
6. we must also update the session's `search_mode_value` when the user types in the search bar? no, because the search bar uses `search_var` (which is also stored per session as `session.search_var`). we are already handling `search_var` by making it a `stringvar` per session and then setting the global `search_var` to that in `render_session`. then we trace the global `search_var` to call `filter_word_list`. but note: the `filter_word_list` uses the global `search_mode` (which is now correctly set to the active session's mode). so that should be fine.
but note: the search bar is also not working. this might be because of a similar issue with `search_var`.
let's look at `search_var`:
- ın the session class, we have: `self.search_var = tk.stringvar()`
- ın `render_session`, we set the global `search_var` to `session.search_var`.
- the search entry is tied to the global `search_var` (which we set at the beginning and then reassign in `render_session`).
the same problem: the entry widget is tied to the initial `search_var`, and then we reassign the global `search_var` to a new `stringvar` from the session. so the entry is still connected to the old one.
we need to do:
- ınstead of reassigning the global `search_var`, we should set the value of the existing global `search_var` to the session's search string? but then how do we handle when the user types? we want the session's `search_var` to update.
alternatively, we can change the entry's `textvariable` to the new `search_var` when we switch sessions.
how about:
- we don't use a global `search_var` for the entry. ınstead, we keep the entry's `textvariable` as the active session's `search_var`.
- ın `render_session`, we set the entry's `textvariable` to the session's `search_var`.
- also, we set the value of the entry to the session's `search_var` value.
but note: we have a trace on `search_var` for filtering. we need to set that trace on the active session's `search_var`.
we can do:
- remove the global `search_var` and instead in the `render_session` function:
# remove any existing trace on the old session's search_var?
# but we don't have a trace on the session's search_var, we have a trace on the global one.
- alternatively, we can have one trace that works for any session by always using the active session? not easily.
- ınstead, we can change the trace to be set on the session's `search_var` when we switch sessions.
proposed for search_var:
step 1: ın the initial setup, we create the entry with a dummy `stringvar` (or an empty one) and store it in a global `search_entry_var` (if needed) but we don't rely on a global variable for the session's search.
step 2: ın `render_session`:
# set the entry's textvariable to the session's search_var
search_entry.config(textvariable=session.search_var)
# also, we need to reapply the trace for the session's search_var to call `filter_word_list`
# but first, remove any existing trace on the previous session's search_var? we don't want multiple traces.
# we can store the trace id and remove it when switching away? alternatively, we can have a single trace that uses the active session.
# alternatively, we can avoid the trace and use a binding on the entry for any key release? but that might be less efficient.
step 3: we set a trace on the session's `search_var` when we activate the session.
however, we cannot easily remove the old trace? we can store the trace id per session? or we can have a single global trace that always uses the active session.
alternatively, we can change the way we filter: we can bind the entry to a function that updates the session's `search_var` and then calls `filter_word_list`. but then we don't use `stringvar` trace.
let me propose a simpler approach:
we don't use `stringvar` for the search entry at all. ınstead, we can:
- ın the session class, store a simple string for the search text: `self.search_text = ""`.
- ın the entry, we can set its value to `session.search_text` when we switch sessions.
- we bind the entry to a function that updates the session's `search_text` and then calls `filter_word_list`.
how about:
def on_search_change(event=none):
session = sessions[active_session_idx]
session.search_text = search_entry.get().lower()
filter_word_list()
search_entry.bind("<keyrelease>", on_search_change)
then in `render_session`:
search_entry.delete(0, tk.end)
search_entry.insert(0, session.search_text)
this way, we don't use `stringvar` at all for the search.
we can do the same for the radio buttons? we don't need `stringvar` for them either? we can store the mode as a string and then set the radio buttons by:
if session.search_mode_value == "eng":
radio_eng.select()
radio_tr.deselect()
else:
radio_eng.deselect()
radio_tr.select()
but then we lose the automatic grouping of radio buttons by the variable.
alternatively, we can have one global `search_mode_var` for the radio buttons and update it when switching sessions, and when it changes, we update the active session. and also update the session when the radio button changes.
given the complexity and time, ı propose a different approach for the radio buttons:
- keep the global `search_mode_var` (which is a `stringvar`) for the radio buttons.
- ın the session class, store the mode as a string (without a `stringvar`).
- when switching sessions:
search_mode_var.set(session.search_mode_value)
- when the radio buttons are changed (i.e., when `search_mode_var` changes), update the active session's `search_mode_value` and then call `filter_word_list`.
we set a trace on `search_mode_var`:
search_mode_var.trace_add("write", lambda *args: on_search_mode_changed())
def on_search_mode_changed():
session = sessions[active_session_idx]
session.search_mode_value = search_mode_var.get()
filter_word_list()
then in `render_session` we set the global `search_mode_var` to the session's value.
and for the search bar, we can do:
we change the entry to not use a `stringvar` but instead we bind to `<keyrelease>` and update the session's `search_text` and then filter.
also, in `render_session`, we set the entry's value to the session's `search_text`.
this avoids the problem of reassigning `stringvar` and breaking the connection.
let's implement:
step 1: change the session class:
class session:
def __init__(self, main_lang, source_lang):
self.data = {"categories": ["genel", "anlamsızlar", "kategorisiz"], "words": []}
self.main_lang = main_lang
self.source_lang = source_lang
self.current_theme = "sepia"
self.search_text = "" # instead of search_var
self.search_mode_value = "eng" # instead of search_mode (stringvar)
self.current_filter = {"category": none, "letter": none}
step 2: ın the global scope, define:
search_mode_var = tk.stringvar(value="eng") # for the radio buttons
# and remove the old global `search_mode` and `search_var`
step 3: create the radio buttons using `search_mode_var`:
radio_eng = tk.radiobutton(..., variable=search_mode_var, value="eng", ...)
radio_tr = tk.radiobutton(..., variable=search_mode_var, value="tr", ...)
step 4: create a function for when the search mode changes:
def on_search_mode_changed(*args):
session = sessions[active_session_idx]
session.search_mode_value = search_mode_var.get()
filter_word_list()
search_mode_var.trace_add("write", on_search_mode_changed)
step 5: for the search bar, we do not use a `stringvar`. ınstead:
- create the entry without a textvariable:
search_entry = tk.entry(search_wrapper, font=("arial", 9), ...)
- bind the entry to update the session's search_text and filter:
def on_search_keyrelease(event):
session = sessions[active_session_idx]
session.search_text = search_entry.get().lower()
filter_word_list()
search_entry.bind("<keyrelease>", on_search_keyrelease)
- also, in `render_session`, we update the entry's content:
search_entry.delete(0, tk.end)
search_entry.insert(0, session.search_text)
step 6: ın `filter_word_list`, we use the active session's `search_text` and `search_mode_value`:
session = sessions[active_session_idx]
search = session.search_text
...
if search:
if session.search_mode_value == "eng":
if search not in eng.lower():
continue
else: # "tr"
if search not in tr.lower():
continue
step 7: ın `render_session`, update the radio buttons and the search entry:
def render_session():
session = sessions[active_session_idx]
# ... other assignments ...
# update the radio buttons
search_mode_var.set(session.search_mode_value) # this will update the selection of radio buttons
# update the search entry
search_entry.delete(0, tk.end)
search_entry.insert(0, session.search_text)
# also update the current_filter? ıt is stored in the session now? actually, we have:
# self.current_filter = {"category": none, "letter": none} # in session __init__
# but we are not storing the current_filter in the session? we are storing it in the session as `current_filter` and we have a global `current_filter` that we set from the session.
# ın the session class, we have `current_filter` as an attribute. so we set the global `current_filter` to session.current_filter? but note we also have a global `current_filter` defined at the bottom? actually, we have:
# current_filter = {"category": none, "letter": none, "search": ""} # at the bottom
# we are setting in `render_session`:
# global ... current_filter ...
# current_filter = session.current_filter # this is now stored per session.
# but note: the `current_filter` in the session does not have a "search" key? ıt only has "category" and "letter". we should add "search" to the session's current_filter? or we are using `session.search_text` for search.
# actually, we are not using the global `current_filter` for search anymore. we are using `session.search_text`. so we can remove the "search" from the global `current_filter`.
# let me adjust: in the session class, in __init__:
# self.current_filter = {"category": none, "letter": none} # we don't need search here
# and in `filter_word_list`, we get the search text from the session.
# also, in the `set_filter` function, we update the session's current_filter:
# session = sessions[active_session_idx]
# session.current_filter["category"] = category
# session.current_filter["letter"] = letter
# and then call `filter_word_list`
# so we need to change `set_filter` to update the active session's current_filter.
# also, in `render_session`, we set the global `current_filter` to the session's current_filter? actually, we don't use the global `current_filter` in `filter_word_list` anymore. we use:
# session = sessions[active_session_idx]
# cat_filter = session.current_filter["category"]
# letter_filter = session.current_filter["letter"]
# search = session.search_text
# so we can remove the global `current_filter` and only use the session's.
# therefore, in `render_session`, we don't need to set a global `current_filter`. we remove it from the global statement and remove the assignment.
# but note: the `set_filter` function currently uses the global `current_filter`. we change it to use the active session.
# let's change `set_filter`:
def set_filter(category=none, letter=none):
session = sessions[active_session_idx]
session.current_filter["category"] = category
session.current_filter["letter"] = letter
filter_word_list()
# and remove the global `current_filter` entirely.
step 8: we must also update the category and letter buttons to reflect the active session's current_filter? actually, no, because the buttons are recreated per session? no, the buttons are global. we are not storing the state of the buttons per session. we are only storing the current_filter in the session.
when we switch sessions, we call `load_category_buttons` and `load_letter_buttons`? yes, in `render_session` we call:
load_category_buttons()
load_letter_buttons()
and in these functions, we use the active session's data to create the buttons. and when we create the buttons, they call `set_filter` which updates the active session's `current_filter`.
so the buttons are recreated for the active session.
step 9: we must also save the session's `search_text`, `search_mode_value`, and `current_filter` when saving sessions? yes, in `save_sessions` we are saving:
session_data = {
"main_lang": session.main_lang,
"source_lang": session.source_lang,
"current_theme": session.current_theme,
"data": session.data
}
we are not saving the search_text, search_mode_value, or current_filter.
we should add them:
session_data = {
...,
"search_text": session.search_text,
"search_mode_value": session.search_mode_value,
"current_filter": session.current_filter # which is a dict with keys "category" and "letter"
}
and when loading:
session = session(...)
session.search_text = session_info.get("search_text", "")
session.search_mode_value = session_info.get("search_mode_value", "eng")
session.current_filter = session_info.get("current_filter", {"category": none, "letter": none})
step 10: we must adjust the `save_sessions` and `load_sessions` accordingly.
given the complexity, we will do:
- change the session class to store the new attributes.
- update `save_sessions` to include them.
- update `load_sessions` to set them.
this is a big refactor. but it should solve both issues.
however, note: the original code is very long and we cannot change everything in one go. we'll do step by step.
due to the complexity and the fact that we are not able to run and test incrementally, ı will provide the changes in code.
but note: the problem of both radio buttons being selected initially should be fixed by using the global `search_mode_var` and setting it in `render_session`.
let's try to fix the radio buttons first without changing the search bar? but the search bar is also broken.
alternatively, we can fix the radio buttons by not reassigning the global `search_mode` in `render_session` but instead setting the value of the existing `search_mode` (the one the radio buttons are tied to) to the session's `search_mode_value` (which we store as a string).
and similarly for the search bar: set the existing `search_var` (which the entry is tied to) to the session's `search_text` by doing:
search_var.set(session.search_text)
but then we must update the session's `search_text` when the user types. we can set a trace on the global `search_var` to update the active session.
how about:
step a: keep the session class as:
class session:
def __init__(self, main_lang, source_lang):
...
self.search_text = ""
self.search_mode_value = "eng"
step b: ın `render_session`:
global search_var, search_mode # these are the global stringvars
session = sessions[active_session_idx]
# for search mode:
search_mode.set(session.search_mode_value) # update the global stringvar for the radio buttons
# for search text:
search_var.set(session.search_text) # update the global search_var for the entry
step c: when the user changes the radio button, we update the active session's `search_mode_value` by:
def update_session_search_mode(*args):
session = sessions[active_session_idx]
session.search_mode_value = search_mode.get()
search_mode.trace_add("write", update_session_search_mode)
step d: similarly, for the search bar:
def update_session_search_text(*args):
session = sessions[active_session_idx]
session.search_text = search_var.get().lower()
search_var.trace_add("write", update_session_search_text)
step e: ın `filter_word_list`, we use the active session's `search_text` and `search_mode_value`:
session = sessions[active_session_idx]
search = session.search_text
mode = session.search_mode_value
... then filter accordingly ...
step f: also, in `set_filter` (for category and letter), we update the session's current_filter? we are already storing current_filter in the session? not exactly. currently, in the session, we don't have current_filter. we have a global `current_filter` that we reassign in `render_session` to the session's `current_filter` (which doesn't exist).
we need to add `current_filter` to the session and use it in `set_filter` and `filter_word_list`.
ın session __init__:
self.current_filter = {"category": none, "letter": none}
ın `render_session`:
global current_filter
current_filter = session.current_filter # this is the global current_filter that is used in set_filter and filter_word_list?
but note: in `set_filter` we are modifying the global `current_filter`:
current_filter["category"] = category
current_filter["letter"] = letter
then in `filter_word_list` we use `current_filter` (global) which now points to the active session's `current_filter` (because we set it in `render_session`).
this should work.
step g: also, when saving sessions, we need to save the new attributes:
session_data = {
...,
"search_text": session.search_text,
"search_mode_value": session.search_mode_value,
"current_filter": session.current_filter # which is a dict
}
and when loading:
session.search_text = session_info.get("search_text", "")
session.search_mode_value = session_info.get("search_mode_value", "eng")
session.current_filter = session_info.get("current_filter", {"category": none, "letter": none})
step h: we must remove the per-session `search_var` and `search_mode` (stringvar) from the session class.
this approach does not break the connection of the entry and the radio buttons because we are always using the same global `search_var` and `search_mode` (stringvars) and just changing their values when switching sessions.
and the trace will update the active session when they change.
also, when the user types or changes the radio button, the active session is updated.
let's implement this.
due to the complexity and the fact that we cannot run the code here, we will provide the code changes accordingly.
however, note that the initial issue of both radio buttons being selected might be because the global `search_mode` was reassigned to a new stringvar, breaking the radio buttons. by not reassigning the global `search_mode` (but only changing its value) we keep the connection.
similarly for the search bar.
we'll change the code in several places.
given the length of the code, ı will now provide the code snippets for the changes.
we'll do:
ın the session class __init__:
remove: self.search_var and self.search_mode
add:
self.search_text = ""
self.search_mode_value = "eng"
self.current_filter = {"category": none, "letter": none}
ın the global scope, keep:
search_var = tk.stringvar() # for the search entry
search_mode = tk.stringvar(value="eng") # for the radio buttons
ın the `render_session` function:
remove: global ... search_var, search_mode, current_filter ...
ınstead, do:
global current_filter # we still have this global? we want to set it to the session's current_filter.
session = sessions[active_session_idx]
# update the global search_mode and search_var to the session's values
search_mode.set(session.search_mode_value)
search_var.set(session.search_text)
current_filter = session.current_filter # this is a dict, so we are making the global current_filter point to the session's current_filter dict
# but note: we also use current_filter in set_filter and filter_word_list. we want them to modify the active session's current_filter.
ın the `save_sessions` function, include the new attributes:
session_data = {
...
"search_text": session.search_text,
"search_mode_value": session.search_mode_value,
"current_filter": session.current_filter
}
ın the `load_sessions` function, when creating the session:
session = session(...)
...
session.search_text = session_info.get("search_text", "")
session.search_mode_value = session_info.get("search_mode_value", "eng")
session.current_filter = session_info.get("current_filter", {"category": none, "letter": none})
also, add traces to update the active session when the global search_mode or search_var change:
def update_session_search_mode(*args):
if sessions: # if there is at least one session
session = sessions[active_session_idx]
session.search_mode_value = search_mode.get()
search_mode.trace_add("write", update_session_search_mode)
def update_session_search_text(*args):
if sessions:
session = sessions[active_session_idx]
session.search_text = search_var.get().lower()
search_var.trace_add("write", update_session_search_text)
and in `filter_word_list`, we now use the active session's current_filter and search_text and search_mode_value? but note: we are using the global `current_filter` and also the session's search_text and search_mode_value.
actually, in `filter_word_list`:
we have:
search = search_var.get().lower() # no! because we are using the session's search_text now.
we should change:
session = sessions[active_session_idx]
search = session.search_text
and for the category and letter filters, we use the global `current_filter` which is now pointing to the active session's current_filter.
but note: in `set_filter` we are modifying the global `current_filter` which is the active session's current_filter.
so in `filter_word_list`:
session = sessions[active_session_idx]
...
cat_filter = current_filter["category"] # global current_filter is the active session's current_filter
letter_filter = current_filter["letter"]
search = session.search_text
this should work.
let's hope.
given the complexity, we might have to adjust.
now, we remove the old global `search_var` and `search_mode` and replace with the new ones.
but note: the code originally had:
search_var = tk.stringvar() # at the top for the search entry
and
search_mode = tk.stringvar(value="eng") # for the radio buttons
and then later, in the top_frame, we create the entry with textvariable=search_var.
and the radio buttons with variable=search_mode.
we are not reassigning these global variables in `render_session` anymore, only setting their values.
this should fix the connection.
let's provide the code changes accordingly.
due to the length, ı will now write the code for the changed parts.
devamını gör...
34.
(bkz: deepseks)
devamını gör...
35.
deepseek-v3.1 yayımlandı:
devamını gör...
36.


değeri yeteri kadar bilinmeyen yakay zekadır.
yazılımds işin teknik tarafını bilenler , hakim olanlar cursor ya da sonnet i daha çok sevsede(çünkü onlar yardımcı olarak kullanıyor, alt yapıları var) bence teknik bilmeyen ve sıfırdan tüm kodu yapay zekaya yazdırıp, uygulama geliştirme manyaklığına girişen biri için biçilmiş kaftan .yani karmaşık süreçleri ve sorunları çözmek için birebir.
3200 satırlık kod satırı olan uygulamayı json yapısından sql yapısına geçirdim sayesinde.
adım adım anlattı ve tek seferde hallettim. chatgpt bir ton karmaşa yaptı, yapılacak gibi değildi mesela ,aşırı göz korkuttu. sonra visual studio copilot ajanına sorduğumda oda abi çok uzun kod dedi, tek tek gidecem diyip düzenleme ayağına kodun %70 silmeyi teklif etti ,yani sapıttı. deepseek ise uzun uzun düşündü ve mükemmel bir rehber hazırlayıp anlattı. deepseek adamdır, diğerleri kumda oynasın. üstelik ücretsiz sekilde bir ton dosya yükleme yapabiliyon tek sorun aynı sohbete ikinci dosyayı atıp konusamiyorsun bağlamı kaybediyor. başka sohbet açıyor yeni belge atınca. en büyük eksisi bu, baska sekmeden önceki sekmeleri konuşmaları tam hatırlamıyor. lakin uzun süre düşünüp çözümleme ve sorun ayıklama, analiz etme konusunda cok başarılı. zaten bu yüzden birden fazla dil modeli ile çalışıyorum.
devamını gör...